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ABSTRACT 


This  thesis  develops  a  prototype  PC  based  Military  Satellite  Communications  (MILSATCOM) 
Requirements  Database  (MRDB)  application  for  U.S.  Space  Command,  using  Microsoft’s  Access 
relational  database  management  system  (DBMS)  for  Windows.  It  demonstrates  the  advantages  of 
using  the  proposed  database  system  over  the  existing  one  and  shows  how  U.S.  Space  Command  can 
save  both  time  and  money  by  using  a  PC  based  interactive,  graphical,  and  user  friendly  database 
system.  A  rapid  prototyping  approach  in  concert  with  a  six  phase  database  design  process  was  used 
to  develop  the  prototype.  The  first  two  chapters  of  the  thesis  provide  a  background  of  the  application 
and  describe  database  management  systems  in  general  and  Microsoft  Access  in  particular.  The 
applications  of  Access  -  tables,  queries,  forms,  reports,  macros,  and  modules  -  to  the  design  of  the 
MRDB  are  then  discussed  in  the  succeeding  five  chapters.  The  conclusions  describe  the  advantages 
and  benefits  of  using  the  prototype  MRDB  database  system  and  make  recommendations  for  future 
improvements. 
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I .  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  thesis  is  to  develop  a  prototype 
Military  Satellite  Communications  (MILSATCOM)  Requirements 
Database  (MRDB)  application  for  U.S.  Space  Command. 
Microsoft's  Access  relational  database  management  system 
(DBMS)  for  Windows  is  the  vehicle  for  this  implementation. 
The  requirements  are  to  build  an  interactive,  graphical  and 
user  friendly  database  system  that  will  allow  U.S.  Space 
Command  to  manage  the  MRDB  database  "in-house". 

B .  BACKGROUND 

In  February  of  1992  the  Naval  Postgraduate  School  was 
approached  by  U.S.  Space  Command  to  assist  in  developing  a 
decision  support  system  for  their  military  satellite 
communications  resources,  to  be  known  as  the  MILSATCOM 
Decision  Support  System  (MDSS) .  The  purpose  of  the  MDSS  is  to 
provide  U.S.  Space  Command  with  an  accurate  and  cost  effective 
means  to  manage  its  communication  resources  for  operational 
planning  and  real-time  status  monitoring.  To  accomplish  this 
task,  the  MDSS  must  be  able  to  store  and  process  current 
satellite  requirements  and  constraints  data,  and  provide 
information  on  individual  MILSATCOM  satellite  constellation 
capabilities.  The  proposed  MDSS  will  consist  of  several 
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different  databases  and  analysis  tools  that  will  be  integrated 
into  a  single  decision  support  system.  One  of  the  databases 
that  will  be  included  in  the  MDSS  is  the  MRDB  database.  [Ref. 
l:p.  1] 

The  MRDB  is  a  database  that  defines  and  contains  all 
unbiased  network  requirements.  Joint  Chiefs  of  Staff  (JCS) 
validated  network  requirements,  and  Commander  in  Chief  (CINC) 
validated  future  network  requirements  for  satellite 
communications.  The  MRDB  is  used  extensively  by  U.S.  Space 
Command,  Air  Force  (AF)  Space  Command,  the  Joint  Staff  (JS) 
and  others  for  MILSATCOM  system  advocacy,  architecture 
development,  operational  planning,  and  requirements 
maintenance.  The  MRDB  currently  contains  over  1,500  network 
requirements  and  will  be  an  integral  part  of  the  MDSS.  [Ref. 
2] 

The  MRDB  was  developed  and  is  currently  maintained  by 
ARINC  Research  Corporation  in  Colorado  Springs,  Co.  ARINC 
uses  INFORMIX  DBMS  software  to  access  and  manipulate  the  data 
in  the  database.  The  current  system,  however,  is  costly  in 
terms  of  both  time  and  dollars.  For  example,  when  U.S.  Space 
Command  wants  to  retrieve  data  from  the  database  or  run  a 
report,  they  must  first  call  or  submit  this  request  to  ARINC. 
ARINC  then  performs  the  retrieval  or  runs  the  report  and 
forwards  this  information  back  to  U.S.  Space  Command.  This 
process  usually  takes  several  days  to  complete.  With  today's 
technology,  the  obvious  question  is  why  can't  U.S.  Space 
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Command  and  others  perform  this  retrieval  without  the  "middle 
man"?  The  intent  of  this  thesis  is  to  demonstrate  that  they 
can. 

C.  BENEFITS  OF  THE  STUDY 

By  showing  how  U.S.  Space  Command  can  save  time  and  money 
using  a  PC  based  interactive,  graphical  database  system  to 
access  and  manipulate  the  data  in  the  MRDB  database,  we  will 
demonstrate  how  they  can  manage  the  MRDB  database  "in-house" 
without  the  assistance  of  a  contractor.  This  work  is  part  of 
an  overall  research  effort  being  conducted  by  the  Naval 
Postgraduate  School  professors  and  students  for  U.S.  Space 
Command . 

0.  SCOPE  OF  THE  THESIS 

The  scope  of  this  thesis  is  to  develop  a  prototype  MRDB 
database  system  based  upon  Microsoft  Access  for  U.S.  Space 
Command.  The  prototype  will  allow  a  functional  user  to 
interactively  access  and  manipulate  the  database  with  ease  and 
demonstrate  the  benefits  of  using  Graphical  User  Interface 
(GUI)  design  principles.  A  dummy  database  will  be  created  to 
populate  and  test  the  system.  This  research  project  is  not 
responsible  for  determining  the  data  requirements  for  the 
database.  These  requirements  are  determined  by  the  thesis 
written  by  Capt  Ron  Kearns,  USAF.  In  his  thesis  the  logical 
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database  structure  is  developed  and  used  in  this  project  for 
the  actual  design  and  development  of  the  database  system. 

E.  METHODOLOGY 

The  goal  of  this  effort  is  to  develop  a  workable  prototype 
based  on  sound  database  design  principles.  We  adopt  a  rapid 
prototyping  approach  to  achieve  this  design.  The  prototype 
database  system  was  developed  using  a  two  activity  approach, 
with  each  activity  being  the  subject  of  a  separate  thesis 
research  project.  This  thesis  concentrates  on  the  second 
activity,  the  actual  design  and  development  of  the  database 
system,  whereas  a  parallel  thesis  by  Capt  Ron  Kearns,  USAF,  is 
responsible  for  the  first  activity,  the  development  of  the 
logical  database  structure.  This  thesis  followed  a  six  phase 
database  design  process  to  develop  the  prototype: 

1.  Requirements  collection  and  analysis. 

2.  Conceptual  database  design. 

3.  Choice  of  a  DBMS. 

4.  Logical  database  design. 

5.  Physical  database  design. 

6.  Database  implementation.  [Ref.  3:p.  458] 

Each  of  these  phases  and  the  methodology  used  is  discussed 
in  more  detail  in  Chapter  II,  in  the  Database  Design 
Methodology  section. 
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F.  ORGANIZATION  OF  THE  THESIS 


This  thesis  consists  of  eight  chapters  supported  by 
several  figures  and  appendices.  The  structure  of  the 
remaining  chapters  is  briefly  summarized  below. 

Chapter  II,  Introduction  to  Databases,  Database  Design 
Methodology,  and  Microsoft  Access,  briefly  discusses  database 
management  systems  in  general  and  Microsoft  Access  in 
particular.  This  chapter  also  describes  the  methodology  used 
in  each  phase  of  the  database  design  process. 

Chapter  III,  MRDB  Application  Tables,  describes  the 
database  schema  and  includes  a  description  of  the  13  tables 
defined  in  the  database. 

Chapter  IV,  MRDB  Application  Queries,  describes  the 
queries  that  were  predefined  and  incorporated  into  the  design 
of  the  database  application.  Tables,  fields,  and  conditions 
used  by  these  queries  are  also  described. 

Chapter  V,  MRDB  Application  Forms,  shows  the  forms  and 
menus  developed  for  this  application,  and  the  interaction  of 
these  forms  and  menus  with  the  menu-driven  system. 

Chapter  VI,  MRDB  Application  Reports,  describes  the  two 
reports  available  in  the  MRDB,  the  content  of  each  report 
section,  and  identifies  the  report  or  sub-report  that 
generates  the  section. 

Chapter  VII,  MRDB  Application  Macros  and  Modules, 
describes  the  macros  and  modules  used  by  this  application. 
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including  the  purpose  of  each  macro  and  module  and  the  actions 
performed  by  them. 

Chapter  VIII,  Conclusions  and  Recommendations,  discusses 
the  advantages  and  benefits  of  using  the  prototype  MRDB 
database  system  and  offers  recommendations  for  future 
development. 
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II.  INTRODUCTION  TO  DATABASES,  DATABASE  DESIGN  METHODOLOGY, 
AND  MICROSOFT  ACCESS 

A.  WHAT  IS  A  DATABASE? 

A  database  is  simply  a  collection  of  records  related  to 
each  other  because  of  their  topic  or  purpose.  For  example, 
military  personnel  records  in  a  filing  cabinet,  a  collection 
of  telephone  numbers  in  a  telephone  book,  or  serial  numbers 
in  a  card  catalog  are  all  examples  of  databases.  [Ref.  4:p.  6] 

B.  WHAT  IS  A  DATABASE  MANAGEMENT  SYSTEM? 

"A  database  management  system  (DBMS)  is  a  system  that 
stores  and  retrieves  information  in  a  database."  [Ref.  4:p.  6] 
It's  the  filing  cabinet  that  stores  personnel  records,  the 
telephone  book  that  contains  telephone  numbers,  or  the  card 
catalog  that  contains  the  serial  numbers  of  books.  A 
computerized  DBMS  is  a  database  that  allows  you  to  store  and 
retrieve  this  data  on  your  computer.  [Ref.  4:p.  6] 

C.  WHAT  IS  AN  INTERACTIVE  AND  GRAPHICAL  DATABASE  SYSTEM? 

An  interactive  database  system  allows  a  user  to  access  and 
update  the  data  in  a  database  in  a  real-time  manner.  A 
graphical  database  is  one  that  uses  visual  features  such  as 
windows,  icons,  buttons,  scroll  bars,  etc.  to  enhance  the  ease 
of  use  of  a  database  system. 
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D.  DATABASE  DESIGN  METHODOLOGY 


The  database  design  process  typically  consists  of  two  main 
activities  that  can  be  divided  into  six  main  phases  or  steps 
as  illustrated  in  Figure  1.  The  first  activity,  accomplished 
by  Capt  Kearns'  thesis,  involves  the  development  of  the 
logical  database  structure,  whereas  the  second  activity, 
accomplished  by  this  thesis,  is  responsible  for  the  actual 
design  and  development  of  the  database  system.  These  two 
activities  are  usually  performed  in  parallel  and  are  closely 
intertwined  and  influenced  by  one  another.  The  six  phases  of 
the  database  design  process  are: 

1.  Requirements  collection  and  analysis. 

2.  Conceptual  database  design. 

3.  Choice  of  a  DBMS. 

4.  Logical  database  design, 

5.  Physical  database  design. 

6.  Database  implementation.  [Ref.  3:p.  458] 

The  following  describes  the  methodology  used  in  each  phase 
of  the  database  design  process  during  the  development  of  the 
MRDB  database. 

1.  Phase  1:  Requirements  Collection  and  Analysis 

Capt  Kearns'  thesis  determined  the  data  requirements 
whereas  we  examined  and  identified  the  intended  uses  of  the 
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Figure  1  Database  Design  Process  [Ref.  3:p.  459] 
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database  system  by  first  reviewing  the  existing  documentation 
of  the  current  MRDB  database  system,  and  then  by  interviewing 
prospective  database  users  at  U.S.  Space  Command  and  Air  Force 
Space  Command. 

2.  Phase  2:  Conceptual  Database  Design 

During  the  conceptual  database  design  phase,  two 
parallel  activities  occur  *■  the  conceptual  schema  design  and 
the  transaction  design.  The  goal  of  the  first  activity  is  to 
transform  the  data  requirements  defined  in  the  first  phase 
into  a  high-level  DBMS- independent  conceptual  database  schema. 
This  part  of  the  design  process  was  accomplished  in  Capt 
Kearns'  thesis.  [Ref.  3:p.  461] 

The  goal  of  the  second  activity  is  to  examine  the 
database  applications  from  the  first  phase  and  determine  which 
transactions  need  to  be  incorporated  into  the  database  system. 
[Ref.  3:p.  461]  During  this  phase  the  four  major  transactions 
were  detailed  by  prospective  users.  They  were  (1)  the  ability 
to  view,  edit,  and  add  the  pertinent  records  to  the  database, 
(2)  the  ability  to  delete  records  from  the  database,  (3)  the 
ability  to  query  the  database,  and  (4)  the  ability  to  produce 
reports  from  the  database.  Each  of  these  transactions  was 
further  divided  into  sub-transactions.  A  complete  discussion 
of  these  transactions  is  presented  in  Chapter  V. 


10 


3.  Phase  3:  Choice  of  a  DBMS 

The  next  phase  in  the  database  design  process  is  to 
select  a  database  management  system  that  is  suitable  for  the 
task  at  hand.  Factors  to  consider  include  technical  and 
performance  characteristics,  the  structure  of  the  database, 
and  the  cost.  [Ref.  3:p.  470]  This  project  required  a  DBMS 
that  is  PC  based,  relational,  graphical,  and  has  powerful 
application  development  tools.  Microsoft  Access  was  selected 
because  it  satisfied  all  of  these  requirements  by  combining 
the  powerful  capabilities  of  a  relational  DBMS  with  the 
graphical  features  available  in  Microsoft  Windows. 

4.  Phase  4:  Logical  Database  Design  Phase 

The  purpose  of  this  phase  is  to  transform  "the 
conceptual  schema  from  the  high-level  data  model  used  in  phase 
2  into  the  data  model  of  the  DBMS  chosen  in  phase  3."  [Ref. 
3:p.  459]  This  part  of  the  process  was  accomplished  by  Capt 
Ron  Kearns  who  converted  the  high-level  entity-relationship 
model  from  the  second  phase  into  a  relational  database  model 
(schema) .  This  thesis  then  used  the  relational  database  model 
to  identify  the  tables  for  the  MRDB  database. 

5.  Phase  5:  Physical  Database  Design 

The  next  step  is  the  physical  database  design  phase. 
The  purpose  of  this  phase  is  to  "specify  the  internal  storage 
structures  and  file  organizations  for  the  database."  [Ref. 
3;p.  39]  During  this  phase  of  the  thesis  the  data  fields,  the 
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primary  and  foreign  keys,  and  the  relationships  between  the 
MRDB  tables  identified  in  the  fourth  phase  were  defined. 

6.  Phase  6:  Database  System  Implementation 

The  bulk  of  this  thesis  was  to  actually  create  and 
implement  the  database  system.  [Ref.  3:p.  474]  This  was  first 
done  by  creating  the  tables  for  the  database  system  and 
populating  them  with  data.  The  next  step  was  creating  the 
queries,  forms,  and  reports  for  the  database  system  and 
integrating  them  together  using  macros  into  a  customized 
application.  The  last  step  was  testinq  the  database  system 
and  demonstrating  the  final  design  to  the  users  at  U.S.  Space 
Command. 

E.  WHAT  IS  MICROSOFT  ACCESS? 

Microsoft  Access  is  a  computerized  database  management 
system  (DBMS)  used  in  conjunction  with  the  Microsoft  Windows 
operating  environment.  It  puts  the  power  to  organize,  locate, 
and  present  information  in  the  hands  of  the  user,  and  takes 
full  advantage  of  the  graphical  power  available  in  Windows, 
giving  the  user  a  visual  means  to  access  and  manipulate  the 
data  in  a  database.  Using  Microsoft  Access,  one  can  easily 
store  information  pertaining  to  different  subjects  in  a 
database,  yet  relate  them  to  each  other  in  a  dynamic  fashion 
through  relationships.  [Ref.  4:pp.  1-6] 
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Microsott  Access  consists  of  six  main  parts  that  allow  a 
user  to  define  the  way  they  want  to  store,  locate,  retrieve, 
and  view  the  data  in  their  database.  The  six  parts  are 
tables,  queries,  forms,  reports,  macros  and  modules.  Each  of 
these  parts  is  briefly  described  below  and  is  detailed  in  the 
succeeding  chapters.  [Ref.  4;pp  8-13] 

1.  Tables 

A  table  is  the  most  basic  element  of  a  database  system 
because  it  defines  where  and  how  the  data  is  stored  in  a 
database.  Tables  define  the  records  and  their  associated  data 
fields  that  make  up  a  database.  A  data  field  is  the  smallest 
unit  of  information  that  describes  something,  such  as  a 
network  ID  or  acronym.  A  record  is  a  collection  of  these  data 
fields,  such  as  a  network  requirement  record,  that  defines  a 
particular  subject  or  thing.  A  table  is  a  collection  of  these 
related  records.  Refer  to  Chapter  III  for  more  information 
on  tables  or  see  Appendix  A  for  an  example  of  a  table.  [Ref. 
4:p.  8] 

2.  Queries  and  Dynasets 

A  query  is  what  makes  a  database  such  a  powerful  tool 
because  it  allows  a  user  to  ask  a  question  about  the  data 
stored  in  the  tables.  For  e.:ample,  someone  might  want  to  know 
all  network  requirements  that  require  anti- jamming.  The  data 
that  answers  that  question  can  come  from  one  or  more  tables. 
A  dynaset  is  a  dynamic  set  of  records  that  represents  the 
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answer  to  a  query.  It  is  called  a  dynaset  because  the  data  of 
the  query  will  be  the  most  current  in  the  database.  A  person 
can  use  a  dynaset  much  like  a  table,  however  the  main 
distinction  between  the  two  is  that  the  data  is  actually 
stored  in  tables  and  not  in  queries  and  dynasets.  [Ref.  4:p. 
9] 

3 .  Forms 

A  form  is  a  predefined,  custom  layout  used  to  enhance 
and  increase  the  efficiency  of  a  database  system.  A  form  can 
be  created  to  view  or  enter  data  in  a  certain  way  or  it  can  be 
created  as  a  menu.  A  menu  offers  the  user  several  different 
options  to  be  executed  on  one  form.  The  user  selects  the 
option  (s)he  wants  by  clicking  the  appropriate  button  or 
marking  the  appropriate  box.  The  advantages  of  using  forms  is 
that  they  greatly  increase  the  readability  of  the  database  by 
allowing  a  user  to  specify  the  unique  way  {s)he  wants  to  see 
their  data.  [Ref.  4:p.  10] 

4.  Reports 

A  report  is  a  meaningful  and  effective  way  to  present 
data  in  a  printed  document.  Like  a  form,  a  report  can  be 
organized  and  formatted  to  a  user's  specifications.  A  report 
can  be  previewed  on  a  user's  terminal  screen  or  it  can  be 
directed  to  a  printer  for  hard  copy  printout.  [Ref.  5;p.  396] 
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5.  Macros 


"A  macro  is  a  list  of  actions  you  want  Microsoft 
Access  to  carry  out  for  you."  [Ref.  4:p.  12]  Macros  can  be 
used  to  automate  routine  or  repetitive  tasks  or  to  integrate 
a  set  of  menus,  forms,  queries,  and  reports  to  work  together 
intelligently  in  a  menu-driven  system.  [Ref.  4:pp.  505-507] 
6.  Modules 

A  module  is  a  collection  of  one  or  more  procedures 
written  in  Access  Basic  that  are  too  complicated  or  complex 
for  a  macro  to  handle.  Procedures  are  written  in  Access 
Basic,  the  built-in  database  programming  language  provided  in 
Access.  [Ref.  4:p.  13] 

The  MRDB  database  system  developed  for  this  thesis  uses 
these  six  components  for  its  implementation.  The  table 
definition  facility  is  used  to  define  the  tables  that 
constitute  the  MRDB  database.  The  query  facility  is  used  to 
define  the  most  commonly  requested  queries.  The  form  facility 
is  used  to  provide  the  user  with  a  convenient  way  to  enter, 
change,  and  view  the  records  in  the  database.  The  report 
facility  is  used  to  produce  the  most  commonly  requested 
reports.  Finally,  macros  and  procedures  are  created  to 
integrate  the  queries,  forms,  and  reports  into  a  customized 
menu-driven  system.  The  application  of  each  of  these 
components  will  be  explained  in  the  succeeding  chapters. 
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III.  MRDB  APPLICATION  TABLES 


A.  DATABASE  SCHEMA 

The  database  design  process  normally  consists  of  two 
parallel  activities  that  are  divided  into  six  main  phases. 
One  of  the  goals  of  the  first  activity  is  to  produce  a  high- 
level  DBMS  dependent  database  schema  [Ref.  3:p.  472]  -  in  this 
case  a  relational  database  schema.  This  is  accomplished 
during  the  logical  database  design  phase  (phase  4)  of  the 
database  design  process.  During  this  phase  the  high-level 
conceptual  schema  produced  in  phase  2  is  transformed  into  the 
data  model  of  the  DBMS  chosen  in  phase  3.  [Ref.  3:p.  459]  The 
result  of  this  phase  is  a  database  schema  in  the  data  model  of 
the  chosen  DBMS.  [Ref.  3:p.  39]  The  database  schema  produced 
during  phase  4  for  this  project  is  shown  in  Figure  2  [Ref. 
6:p.  60].  This  model  was  developed  by  Capt  Kearns  for  his 
thesis  and  is  used  here  to  accomplish  phases  5  and  6.  Since 
the  DBMS  selected  for  this  project  is  relational,  the  DBMS 
dependent  data  model  shown  in  Figure  2  is  called  the  MRDB 
relational  model  (schema) .  This  model  identifies  the  tables 
of  the  MRDB  database  and  shows  the  relationships  between  them. 
Once  these  tables  are  identified,  one  can  proceed  with  the 
physical  design  phase  of  the  database. 
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The  MRDB  relational  model  shown  in  Figure  2  shows  that 
the  database  is  centered  around  the  network  table.  The 
network  table  defines  a  network  requirement  for  a  CINC  and  its 
component.  Each  network  consists  of  one-to-many 
connectivities.  Connectivities  are  connections  between  two 
terminals  and  their  users  located  throughout  the  world.  These 
locations  are  defined  in  the  geo-location  table.  Each 
terminal  has  a  unique  set  of  characteristics  specified  in  the 
terminal  type  table.  In  addition,  networks  can  have  one-to- 
many  points  of  contact  (POC)  who  are  responsible  for  the 
network  requirement,  and  each  network  can  reference  one-to- 
nany  documents.  For  a  complete  description  of  this  database 
schema,  please  refer  to  the  thesis  written  by  Capt  Kearns. 

B.  TABLES 

The  first  step  in  the  physical  database  design  phase 
(phase  5)  is  defining  the  tables  for  the  MRDB  database.  The 
database  schema  produced  during  the  logical  database  design 
phase  identified  13  tables  to  be  included  in  the  database. 
Each  of  these  tables  is  briefly  described  below.  For  a 
complete  definition  of  these  tables,  please  see  Appendix  A. 

1.  Network  Table 

The  network  table  is  the  largest  and  most  important 
table  in  the  database.  All  other  tables  either  further  define 
or  provide  additional  information  regarding  a  network 
requirement.  The  network  table  defines  a  requirement  for  a 
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communication  network  that  will  satisfy  the  communication 
needs  for  a  particular  CINC.  It  is  identified  by  a  network-ID 
and  includes  basic  information  regarding  the  requirement  such 
as  the  network  name,  the  primary  and  secondary  missions  of  the 
network,  the  mission  definition  of  the  network,  the  priorities 
of  the  network,  and  the  general  capabilities  and 
specifications  the  network  should  have.  A  network  usually  has 
several  connectivities,  is  associated  with  a  CINC,  has  several 
POCs  and  several  documents. 

2.  Connectivity  Table 

The  second  most  important  table  in  the  database  is  the 
connectivity  table.  The  connectivity  table  describes  the 
unique  connectivities  that  make  up  a  network.  A  connectivity 
is  any  connection  between  two  terminals  that  provide  some  type 
of  communication  capability  to  a  user.  For  every  unique 
connectivity  there  is  a  unique  connectivity  record.  A  network 
requirement  usually  necessitates  several  connectivities  in 
order  to  satisfy  the  requirement.  In  the  current  MRDB  there 
are  over  10,000  connectivities  defined,  each  one  belonging  to 
a  particular  network.  The  connectivity  table  is  identified  by 
a  connectivity-ID  and  includes  basic  information  regarding  a 
connection  such  as  the  connectivity  type,  the  connectivity 
data  type,  the  operation  mode,  and  the  stress  and  unstressed 
throughput  and  data  rates  of  a  connection.  A  connectivity 
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usually  consists  of  two  terminals  -  the  originating  terminal 
and  the  destination  terminal. 

3.  Terminal  Table 

Whereas  the  connectivity  table  describes  the  unique 
connections  that  make  up  a  network,  the  terminal  table  defines 
the  unique  terminals  that  make  up  these  connections.  The 
terminal  table  is  identified  by  a  terminal-ID  and  includes  the 
geo-location  of  the  terminal,  the  terminal  nomenclature,  the 
reporting  designator,  the  serial  number,  the  activation  and 
deactivation  dates,  and  remarks.  Each  terminal  has  a  unique 
terminal  type,  location,  and  user  associated  with  it,  but  a 
terminal  can  belong  to  several  connectivities. 

4 .  Terminal-Connect  Table 

Since  a  terminal  at  a  particular  location  can  be  used 
by  many  different  connections  and  a  connection  can  have  more 
than  one  terminal  (maximum  of  two)  ,  the  purpose  of  this 
intersection  table  is  to  specify  which  terminals  (defined  in 
the  terminal  table)  belong  to  which  connectivities  (specified 
in  the  connectivity  table) .  This  table  is  identified  by  a 
connectivity-ID  and  a  terminal-ID  and  specifies  if  the 
terminal  of  a  particular  connection  is  the  originating  or  the 
destination  terminal  of  a  connection. 

5.  Terminal  Type  Table 

The  terminal  type  table  defines  the  detailed 
characteristics  of  the  terminals  specified  in  the  terminal 
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table.  The  table  is  identified  by  the  terminal  nomenclature 
and  includes  information  such  as  the  frequency  and  mobility  of 
these  terminals,  their  platforms,  the  antenna  size,  and  their 
minimum  and  maximum  data  rates.  A  terminal  type  can  be 
specified  by  one  or  more  terminals. 

6.  User  Table 

The  user  table  describes  the  users  of  the  t-.minals 
defined  in  the  terminal  table  and  defines  the  name  and  geo¬ 
location  of  these  users.  The  table  is  identified  by  a  user- 
ID.  A  user  can  be  associated  with  one-to-many  terminals. 

7 .  Geo-Location  Table 

The  purpose  of  the  geo-location  table  is  to  give  a 
complete  description  of  the  locations  defined  in  the  terminal 
and  user  tables.  The  geo-location  table  is  identified  by  a 
geo-location-code  and  includes  information  regarding  a 
location  such  as  the  full  location  name,  the  state-country 
code,  the  area  code,  and  the  lat  and  long  information  of  a 
location.  This  table  is  a  standard  reference  file  maintained 
by  the  Department  of  Defense  and  as  such  is  not  accessible  for 
update  by  the  user  through  the  application  system. 

8 .  POC  Table 

The  POC  table  defines  the  points  of  contact 
responsible  for  network  requirements.  The  POC  table  is 
identified  by  a  POC-ID  and  includes  vital  information 
regarding  the  points  of  contact  such  as  a  person's  name. 
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address,  and  telephone  numbers.  A  point  of  contact  can  be 
responsible  for  one-to-many  networks. 

9.  Netvork-POC  Table 

Since  one  POC  can  be  responsible  for  several  network 
requirements  and  a  network  requirement  can  have  more  than  one 
POC,  the  purpose  of  the  Network-POC  intersection  table  is  to 
link  a  POC  to  a  network  requirement.  This  table  is  identified 
by  a  network-lD  and  a  POC-ID  and  includes  no  other  additional 
attributes. 

10.  Document  Table 

The  document  table  describes  the  documents  referenced 
by  network  requirements.  The  document  table  is  identified  by 
a  document-ID  and  includes  the  title,  author,  publication 
date,  and  classification  of  the  documents.  A  document  can  be 
referenced  by  many  different  networks. 

11.  Network*>Ref-Doc\unent  Table 

Since  a  document  can  be  referenced  by  many  networks 
and  a  document  can  refer  to  several  networks,  the  purpose  of 
the  network-ref-document  intersection  table  is  to  identify 
which  documents  are  referenced  by  each  one  of  the  networks. 
In  addition  to  establishing  the  linkage  between  the  network 
table  and  the  document  table,  the  network-ref-document  table 
also  includes  the  page  numbers  of  the  document  that  is 
referenced  by  a  particular  network.  This  intersection  table 
is  identified  by  a  document-lD  and  a  network-ID. 
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12.  CINC  Tabl« 


The  CINC  table  consists  of  the  CINC  name  and  is  used 
to  provide  the  linkage  between  the  network  table  and  the  CINC 
component  table.  The  CINC  table  is  identified  by  a  CINC-name 
and  can  be  referenced  by  many  different  networks. 

13 .  Component  Table 

The  component  table  specifies  the  valid  component 
names  that  belong  to  a  CINC.  This  table  is  primarily  used  for 
validation  purposes  to  ensure  that  a  valid  component  is 
entered  in  the  network  table  when  specifying  a  CINC's 
component.  This  table  is  identified  by  a  component-name  and 
includes  the  CINC  name  for  each  component.  A  component  can  be 
referenced  by  many  different  networks  and  belongs  to  only  one 
CINC. 

Once  these  tables  are  defined,  we  can  now  begin  the 
development  of  the  queries,  forms,  reports,  macros,  and 
modules  for  the  application.  The  next  chapter  describes  the 
queries  that  were  developed  for  the  MRDB  database  system. 
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IV.  MRDB  APPLICATION  QUERIES 


In  Microsoft  Access  a  query  can  be  designed  to  retrieve 
certain  records  from  a  database  or  to  select  certain  fields 
from  a  table  [Ref.  5:p.  93].  The  answer  to  a  query  is  called 
a  dynaset  [Ref.  4:p.  9].  "A  dynaset  is  a  dynamic  set  of 
records  that  contains  data  drawn  from  one  or  more  tables.” 
[Ref.  4:p.9]  In  Access  you  can  query  the  database  for  just 
about  anything  using  the  graphical  Query  by  Example  feature 
which  allows  a  user  to  compose  ad-hoc  queries  of  arbitrary 
complexity  by  specifying  the  tables,  data  fields,  and  criteria 
of  a  query  [Ref.  5:pp.  95-96].  Incorporated  into  the  design 
of  this  application  are  three  of  the  more  common  queries 
requested  by  U.S.  Space  Command.  The  three  queries  are  (1) 
networks  by  operational  dates,  (2)  networks  by  CINCs  and  their 
components,  and  (3)  networks  limited  by  requirements  (such  as 
satisfaction  level,  anti-jam  criteria,  access  criteria,  etc)  . 
A  user  can  select  the  query  {s)he  wants  from  a  menu  and 
specify  its  parameters.  (The  menus  that  make  up  the  query 
portion  of  the  database  are  discussed  in  more  detail  in 
Chapter  V.  Please  refer  to  that  chapter  for  the  actual 
displays  that  generate  these  queries) .  In  addition  to  the 
three. predefined  queries,  there  are  31  additional  queries  used 
to  generate  reports,  provide  information  for  combo  boxes 
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(i.e.,  look  up  tables),  and  display  information  related  to 
particular  records.  See  Appendix  B  for  a  complete  listing  of 
all  the  queries  used  by  this  database.  The  following  sections 
briefly  describe  the  three  predefined  queries  available  to  a 
user. 

A.  NETWORKS  BY  OPERATIONAL  DATES 

The  query,  networks  by  operational  dates,  queries  the 
database  for  all  network  requirements  that  fall  within  the 
beginning  and  ending  operational  dates  as  specified  by  the 
user.  The  query  accesses  only  one  table,  the  network  table, 
to  generate  this  information.  The  query  returns  all  network 
requirements  that  fall  within  the  specified  range  and  displays 
them  in  ascending  order  by  network  acronym.  The  data  fields 
displayed  for  each  network  requirement  selected  are  network 
acronym,  network  name,  network-ID,  requirement  begin  date,  and 
the  requirement  end  date. 

B.  NETWORKS  BY  CINCS  AND  THEIR  COMPONENTS 

The  query,  networks  by  CINCs  and  their  components,  queries 
the  network  table  for  all  network  requirements  that  match  the 
CINC  and  component  name  specified  by  a  user.  This  query  is 
actually  performed  by  one  of  three  sub-queries  depending  upon 
what  information  is  specified  by  the  user.  If  a  user 
specifies  both  a  CINC  and  a  component  name,  then  the  sub¬ 
query,  networks  by  CINC  and  component,  is  generated.  If  a 
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user  specifies  only  a  CINC,  then  the  sub-query,  networks  by 
CINC  name  only,  is  generated.  If  a  user  doesn't  specify 
either  a  CINC  or  a  component  name  (i.e.,  the  user  leaves  the 
input  fields  blank) ,  then  the  sub-query,  all  networks  listed 
by  CINC  and  component,  is  generated.  The  data  fields 
displayed  for  each  sub-query  are  CINC,  component,  network 
acronym,  network-ID,  and  network  name.  The  three  sub-queries 
are  discussed  below. 

1.  Networks  by  CINC  and  Component 

This  sub-query  will  search  and  display  all  network 
requirements  that  match  both  the  CINC  and  the  component  name 
as  specified  by  the  user. 

2.  Networks  by  CINC  Name  Only 

This  sub-query  will  search  and  display  all  network 
requirements  that  match  the  CINC's  name.  All  the  components 
of  the  specified  CINC  are  displayed. 

3.  All  Networks  listed  by  CINC  and  Component 

This  sub-query  will  display  all  network  requirements 
in  ascending  order  by  CINC  and  within  each  CINC  in  ascending 
order  by  component. 

C.  NETWORKS  LIMITED  BY  REQUIREMENTS 

The  query,  networks  limited  by  requirements,  queries  the 
network  table  for  all  networks  requirements  that  match  the 
criteria  specified  by  a  user.  The  user  can  limit  the  search 
according  to  the  following  criteria. 
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-  Satisfaction  level 

-  Network  excluded 

-  Network  critical 

-  Anti- jamming  (AJ) required 

-  Anti-jamming  critical 

-  Low  probability  of  intercept  (LPI)  required 

-  Low  probability  of  intercept  critical 

-  Nuclear  scintillation  protection  (NSP)  required 

-  Electromagnetic  pulse  protection  (EMP)  critical 

-  Anti-spoof  critical 

-  Access  critical 


The  user  can  specify  criteria  for  all,  some,  or  none  of 
these  attributes.  This  query  is  actually  performed  by  one  of 
two  sub-queries  depending  on  whether  a  satisfaction  level  is 
specified  or  not.  If  a  user  specifies  a  satisfaction  level, 
then  the  sub-query,  networks  by  satisfaction  level,  is 
generated.  However  if  a  user  does  not  specify  a  satisfaction 
level  (i.e.,  the  user  leaves  the  field  blank),  then  the  sub¬ 
query,  networks  by  all  satisfaction  levels,  is  generated.  The 
data  fields  displayed  for  each  sub-query  are  network  acronym, 
network  name,  and  network-ID.  The  two  sub-queries  are 
discussed  below. 

1.  Networks  by  Satisfaction  Level 

This  sub-query  is  generated  if  a  satisfaction  level  is 
specified  by  a  user.  The  sub-query  will  display  all  network 
requirements  that  match  the  satisfaction  level  specified  as 
well  as  any  other  restrictions  that  might  be  specified.  This 
sub-query  accesses  the  network  table  to  provide  this 
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information  and  displays  the  network  requirements  in  ascending 
order  based  on  the  netwc  acronym. 

2.  Networks  by  All  Satisfaction  Levels 

This  sub-query  is  generated  if  a  satisfaction  level  is 
not  specified  by  a  user.  The  sub-query  will  display  all 
network  requirements  that  match  the  restrictions  specified  by 
the  user  for  all  satisfaction  levels.  This  sub-query  accesses 
the  network  table  to  provide  this  information  and  displays  the 
network  requirements  in  ascending  order  based  on  the  network 
acronym. 

Whereas  this  chapter  described  the  queries  ir  the  MRDB 
database  system,  the  next  chapter  describes  the  forms  that 
have  been  developed  for  the  database  system. 
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V.  MRDB  APPLICATION  FORMS 


Forms  are  predefined,  customized  layouts  that  allow  a  user 
to  create,  modify,  or  display  data  in  a  database.  Forms  can 
also  be  used  to  create  menus  for  a  menu-driven  database 
system.  By  creating  a  menu-driven  database  system,  custom 
applications  can  be  built  that  allow  a  user  to  navigate 
relatively  easily  through  the  database  without  having  to  know 
much  about  the  database  management  software  or  the  structure 
of  the  database.  The  database  system  developed  for  this 
thesis  is  menu-driven  and  consists  of  several  menus  and  forms 
that  have  been  integrated  to  make  a  user  friendly  system. 
Figure  3  shows  the  menu  hierarchy.  The  following  sections 
discuss  each  of  these  forms  in  detail  and  show  an  example  of 
each  one  on  the  corresponding  pages. 


..  Ct 

*>  e 

^  § 

UJ,  K, 


3 

8  t 

%  “ 

o  >. 

8  I 


S 


"  " 
J!  "S- 

e  S 
ku  q 

_i_J 


W  M 
X  • 
>  ? 


i  I 

«  c 


a  I 

.S  ^ 


1 1, 1 1 


30 


Figure  3  Menu  Hierarchy 


A.  MAIN'DRIVER  MENU 


The  Main-Driver  menu  shown  in  Figure  4  is  the  first  form 
that  appears  when  a  user  invokes  the  MRDB  database 
application.  The  Main-Driver  menu  displays  the  five  major 
actions  that  a  user  can  perform  on  the  database.  The  five 
actions  are  (1)  view/edit  records,  (2)  delete  records,  (3) 
query  data,  (4)  generate  reports,  or  (5)  exit  the  database 
system.  A  user  selects  these  actions  by  pointing  and  clicking 
the  appropriate  button  on  the  menu.  Each  of  these  selections 
and  the  actions  performed  by  them  are  briefly  described  below. 

1.  View-Edit  Button 

Clicking  this  button  causes  the  View-Edit-Selection 
menu  to  appear.  This  menu  allows  the  user  to  view,  edit,  or 
add  a  new  network  requirement,  connectivity,  CINC,  POC, 
document,  terminal,  terminal  type  or  user  to  the  database. 

2.  Delete  Button 

Clicking  this  button  causes  the  Delete-Dialog  form  to 
appear.  The  Delete-Dialog  form  gives  instructions  on  how  to 
delete  a  network  requirement,  connectivity,  CINC,  POC, 
document,  terminal,  terminal  type  or  user  from  the  database. 

3.  Queries  Button 

Clicking  this  button  causes  the  Query-Selection  form 
to  appear.  This  form  allows  a  user  to  invoke  any  of  the 
predefined  queries.  The  three  choices  available  are  networks 
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Figure  4  Main  Driver  Menu 
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by  operational  dates,  networks  by  CINC  and  components,  and 
networks  limited  by  requirements. 

4.  Reports  Button 

Clicking  this  button  causes  the  Report-Selection  form 
to  appear.  This  form  allows  a  user  to  preview  or  print  the 
Detailed  report  or  the  Terminal  User  Report. 

5.  Exit  Button 

Clicking  this  button  causes  the  user  to  exit  the 
database  system  and  return  to  the  application  that  invoked 
this  application. 
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B.  VIEW-EDIT-SELECTION  MENU 


The  View-Edit-Selection  menu  shown  in  Figure  5  displays 
the  tables  that  can  be  viewed,  edited,  or  added  in  the 
database.  A  user  selects  one  of  these  tables  by  clicking  the 
appropriate  button  on  the  menu  or  selects  the  "Return”  button. 
Each  of  these  selections  and  the  actions  performed  by  them  are 
described  below. 

1.  View  Network  Button 

Clicking  this  button  causes  the  Network-Update  form  to 
appear.  This  form  allows  a  user  to  view,  edit,  or  add  a  new 
record  to  the  Network  table. 

2.  View  CINC  Button 

Clicking  this  button  causes  the  CINC-Update  form  to 
appear.  This  form  allows  a  user  to  view,  edit,  or  add  a  new 
record  to  the  CINC  table. 

3.  View  POC  Button 

Clicking  this  button  causes  the  POC-Update  form  to 
appear.  This  form  allows  a  user  to  view,  edit,  or  add  a  new 
record  to  the  POC  table. 

4.  View  DOC  Button 

Clicking  this  button  causes  the  Document-Update  form 
to  appear.  This  form  allows  a  user  to  view,  edit,  or  add  a 
new  record  to  the  Document  table. 
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Figure  5  View-Edit-Selection  Menu 


5.  View  Connectivity  Requirement  Button 

Clicking  this  button  causes  the  Connectivity-Update 
form  to  appear.  This  form  allows  a  user  to  view,  edit,  or  add 
a  new  record  to  the  Connectivity  table. 

6.  View  Terminal  Button 

Clicking  this  button  causes  the  Terminal-Update  form 
to  appear.  This  form  allows  a  user  to  view,  edit,  or  add  a 
new  record  to  the  Terminal  table. 

7.  View  Terminal-Type  Button 

Clicking  this  button  causes  the  Terminal-Type-Update 
form  to  appear.  This  form  allows  a  user  to  view,  edit,  or  add 
a  new  record  to  the  Terminal-Type  table. 

8.  View  User  Button 

Clicking  this  button  causes  the  User-Update  form  to 
appear.  This  form  allows  a  user  to  view,  edit,  or  add  a  new 
record  to  the  User  table. 

9 .  Return  Button 

Clicking  this  button  causes  the  View-Edit-Selection 
menu  to  disappear  and  returns  the  user  to  the  Main-Driver 
menu. 
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C .  NETWORK-UPDATE  FORM 

The  Network-Update  form  shown  in  Figure  6  allows  a  user  to 
view,  update,  and/or  add  a  network  requirement  to  the 
database.  The  form  consists  of  three  pages  of  data.  A  user 
can  move  from  one  page  to  another  by  pressing  the  "Page  Down” 
or  the  "Page  Up"  button  located  on  the  keyboard.  The  form  also 
consists  of  six  action  buttons  on  the  top  of  the  form  and  a 
"Return  to  Menu"  button  on  the  bottom.  The  "Return  to  Menu" 
button  is  used  to  return  to  the  View-Edit-Selection  menu  when 
the  user  is  finished  with  the  Network-Update  form.  The 
actions  of  the  six  other  buttons  are  described  in  the 
succeeding  pages. 
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Figure  6  (Page  1  of  3)  Network-Update  Form 
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1.  Vi«w  Conn«ctiviti«8  Button 

Clicking  this  button  causes  the  Network-View- 
Connectivity  form  to  appear  in  conjunction  with  the  Network- 
Update  form.  These  forms  are  shown  in  Figure  7.  The  Network- 
View-Connectivity  form  displays  the  connectivities  that  belong 
to  the  network  requirement  currently  shown  on  the  Network- 
Update  form. 
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Figure  7  Network- View-Connectivity  Form 
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2.  Add  Connectivity  Button 

Clicking  this  button  causes  the  Network-Add- 
Connectivity  form  to  appear  in  conjunction  with  the  Network- 
Update  form.  These  forms  are  shown  in  Figure  8.  The  Network- 
Add-Connectivity  form  allows  a  user  to  add  a  connection  to  the 
current  network  requirement  shown  on  the  Network-Update  form. 
The  form  consists  of  the  data  fields  that  define  a 
connectivity,  two  action  buttons,  and  a  "Return"  button. 
Clicking  the  "Return"  button  causes  the  user  to  return  to  the 
Network-Update  form.  The  actions  of  the  other  two  buttons  are 
described  in  the  succeeding  pages. 
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Figure  8  Network-Add-Connectivity  Form 
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a.  View  Terminals  Button 

Clicking  this  button  causes  the  Network-Add-Conn- 
View-Terminals  form  to  appear  in  conjunction  with  the  Network- 
Update  form  and  the  Network-Add-Connectivity  form.  These 
forms  are  shown  in  Figure  9.  The  Network-Add-Conn-View- 
Terminals  form  displays  the  origin  and  destination  terminals 
of  the  current  connection  displayed  on  the  Network-Add- 
Connectivity  form. 
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Figure  9  Network-Add-Conn-View-Terminals  Form 
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b.  Add  Terminals  Button 

Clicking  this  button  causes  the  Network-Add-Conn- 
Add-Terminals  form  to  appear  in  conjunction  with  the  Network- 
Update  form  and  the  Network-Add-Connectivity  form.  These 
forms  are  shown  in  Figure  10.  The  Network-Add-Conn-Add- 
Terminals  form  allows  a  user  to  add  a  terminal  to  the  current 
connectivity  displayed  on  the  Network-Add-Connectivity  form. 
The  form  consists  of  both  a  main  form  and  a  subform.  The  main 
form  contains  the  data  fields  that  define  a  terminal  and  the 
subform  allows  a  user  to  link  the  terminal  to  a  particular 
connectivity.  Clicking  the  "Return"  button  on  this  form 
returns  the  user  to  the  Network-Add-Connectivity  form. 


47 


Figure  10  Network-Add-Conn-Add-Terminals  Form 
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3.  View  POC  Button 


Clicking  this  button  causes  the  Network -View-POC  form 
to  appear  in  conjunction  with  the  Network-Update  form.  These 
forms  are  shown  in  Figure  11.  The  Network -View-POC  form 
displays  the  points  of  contact  that  belong  to  the  network 
requirement  currently  shown  on  the  Network-Update  form. 
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Figure  11  Network-View-POC  Form 
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4.  Add  POC  Button 


Clicking  this  button  causes  the  Network-Add-POC  form 
to  appear  in  conjunction  with  the  Network-Update  form.  These 
forms  are  shown  in  Figure  12.  The  Network-Add-POC  form  allows 
a  user  to  add  a  POC  to  the  current  network  requirement  shown 
on  the  Network-Update  form.  The  form  consists  of  both  a  main 
form  and  a  subform.  The  main  form  contains  the  data  that 
defines  a  point  of  contact  and  the  subform  allows  a  user  to 
link  the  POC  to  a  particular  network.  Clicking  the  "Return" 
button  on  this  form  returns  the  user  to  the  Network-Update 
form. 
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Figure  12  Network-Add-POC  Forin 
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5.  View  Document  Button 

Clicking  this  button  causes  the  Network -View-Document 
form  to  appear  in  conjunction  with  the  Network-Update  form. 
These  forms  are  shown  in  Figure  13.  The  Network -View-Document 
form  displays  the  documents  referenced  by  the  network 
requirement  currently  shown  on  the  Network-Update  form. 
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Figure  13  Network-View-Document  Form 


54 


6.  Xdd  Docufflent  Button 


Clicking  this  button  causes  the  Network-Add-Document 
form  to  appear  in  conjunction  with  the  Network-Update  form. 
These  forms  are  shown  in  Figure  14.  The  Network -Add-Document 
form  allows  a  user  to  add  a  document  to  the  network 
requirement  currently  shown  on  the  Network-Update  form.  The 
form  consists  of  both  a  main  form  and  a  subform.  The  main 
form  contains  the  data  fields  that  define  a  document  and  the 
subform  allows  a  user  to  link  the  document  to  a  particular 
network  requirement.  Clicking  the  ••Return”  button  on  this 
form  returns  the  user  to  the  Network-Update  form. 
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Figure  14  Network-Add-Docuinent  Form 
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D.  CONNECTIVITY-UPDATE  FORM 


The  Connectivity-Update  form  shown  in  Figure  15  allows  a 
user  to  view,  update,  and/or  add  connectivities  to  the 
database.  The  form  consists  of  the  data  fields  that  define  a 
connectivity,  two  action  buttons,  and  a  "Return  to  Menu" 
button.  Clicking  the  "Return  to  Menu"  button  causes  the  user 
to  return  to  the  View-Edit-Selection  menu.  The  actions  of  the 
other  two  buttons  are  described  in  the  succeeding  pages. 
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Figure  15  Connectivity-Update  Form 
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1.  view  Terminals  Button 

Clicking  this  button  causes  the  Connectivity-View- 
Terminals  form  to  appear  in  conjunction  with  the  Connectivity- 
Update  form.  These  forms  are  shown  in  Figure  16.  Tne 
Connectivity-View-Terminals  form  displays  the  originating  and 
destination  terminals  of  the  connection  currently  shown  on  the 
Connectivity-Update  form. 


59 


Microsoft  Access  -  |ConneclMty{ 


file  Edit  yiew  Becords  ^ndow  Help 


3  fiddi^BaltonSS 


JmI 


Connecfivily  Specifications 

Cofineetivilf  ID:  j  1 


IVigwTeriin 


Nstwoik:  r 


AFSCNiaj 


jyd  Term  t 


Conmclivitf  Ifps:  |PT-PT 
Mode  of  opsfStion: 


m 


IE 


Connodivily  cittcol  (Y/N}?:  (FT 
iSDBNuMbor:  r~ 


CCSD  Rostora  piioritr:  f 
Sliossod  dalolm 
UraUoMod  dotal 
Streoted  II 
Untlietred  thni' 


,'.y 


DaUTfpa:  [Data 
Nioabof  of  ciiciat:  | 
Secure  at  enctipied  (YyN|7:  [n 
fXSDNusdMT  j 
Satie*  nwoe:  I 


View-Terniitials 


IB 


ISQl^^SEii 


Uraque  tucae  or  detagnStor  9won  to  elananal 


to  Menu 


ittJR 


NUM 


Figure  16  Connect ivity-View-Terininals  Form 
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2.  Add  Tarmlnals  Button 

Clicking  this  button  causes  the  Connectivity-Add- 
Terminal  form  to  appear  in  conjunction  with  the  Connectivity- 
Update  form.  These  forms  are  shown  in  Figure  17.  The 
Connectivity-Add-Terminal  form  allows  a  user  to  add  a  terminal 
to  the  connectivity  displayed.  The  form  consists  of  both  a 
main  form  and  a  subform.  The  main  form  contains  the  data 
fields  that  define  a  terminal  and  the  subform  allows  a  user  to 
link  the  terminal  to  a  particular  connectivity.  Clicking  the 
"Return"  button  on  this  form  returns  the  user  to  the 
Connectivity-Update  form. 
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E.  CINC-UPDATE  FORM 


The  CINC-Update  form  shown  in  Figure  18  allows  a  user  to 
view,  update  and/or  add  CINCs  and  their  components  to  the 
database.  The  CINC-Update  form  consists  of  both  a  main  form 
and  a  subform.  The  main  form  contains  the  data  field  that 
defines  a  CINC  and  the  subform  allows  a  user  to  define  the 
components  for  that  CINC.  Clicking  the  "Return-to-Menu" 
button  on  this  form  returns  the  user  to  the  View-Edit- 
Selection  menu. 
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Figure  18  CINC-Update  Form 
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F.  POC-UPDATE  FORM 

The  POC-Update  form  shown  in  Figure  19  allows  a  user  to 
view,  update  and/or  add  points  of  contact  to  the  database. 
The  POC-Update  form  consists  of  both  a  main  form  and  a 
subform.  The  main  form  contains  the  data  that  defines  a  point 
of  contact  and  the  subform  allows  a  user  to  link  the  POC  to  a 
particular  network.  Clicking  the  "Return-to-Menu”  button  on 
this  form  returns  the  user  to  the  View-Edit-Selection  menu. 
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Figure  19  POC-Update  Form 
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G.  DOCUMENT^UPDATE  FORM 

The  Docuroent-Update  form  shown  in  Figure  20  allows  a  user 
to  view,  update  and/or  add  documents  to  the  database.  The 
Document-Update  form  consists  of  a  main  form  that  defines  a 
document  and  a  subform  that  allows  a  user  to  link  the  document 
to  a  particular  network  requirement.  Clicking  the  ”Return- 
to-Menu"  button  on  this  form  returns  the  user  to  the  View- 
Edit-Selection  menu. 
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H.  TERMINAL-UPDATE  FORM 


The  Terminal-Update  form  shown  in  Figure  21  allows  a  user 
to  view,  update  and/or  add  terminals  to  the  database.  The 
form  consists  of  a  main  form  and  a  subform.  The  main  form 
contains  the  data  fields  that  define  a  terminal  and  the 
subform  allows  a  user  to  link  a  terminal  to  a  particular 
connectivity.  Clicking  the  "Return-to-Menu”  button  on  this 
form  returns  the  user  to  the  View- Edit-Selection  menu. 
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Figure  21  Terminal-Update  Form 
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I .  TERMINAL-TYPE-DPDATE  FORM 

The  Terminal-Type-Update  form  shown  in  Figure  22  allows  a 
user  to  view,  update  and/or  add  terminal  type  specifications 
to  the  database.  The  form  consists  of  a  main  form  that 
specifies  the  actual  characteristics  of  terminals  and  a 
subform  that  displays  which  terminal  IDs  and  users  reference 
this  particular  terminal  type.  Clicking  the  "Return-to-Menu" 
bvitton  on  this  form  returns  the  user  to  the  View-Edit- 
Selection  menu. 


71 


Figure  22  Terminal-Type-Update  Form 
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J.  USER-UPDATE  FORM 

The  User-Update  form  shown  in  Figure  23  allows  a  user  to 
view,  update,  and/or  add  users  to  the  database.  The  form 
consists  of  a  main  form  and  a  subform.  The  main  form  defines 
the  name  and  location  of  a  particular  user  and  the  subform 
displays  the  terminals  used  by  this  particular  user.  Clicking 
the  "Return-to-Menu"  button  on  this  form  returns  the  user  to 
the  View-Edit-Selection  menu. 
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Figure  23  User-Update  Form 
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K .  DELETE-DIALOG  FORM 

The  Delete-Dialog  form  shown  in  Figure  24  provides 
instructions  on  how  to  delete  a  record  from  the  database. 
From  this  form  a  user  can  either  select  the  "OK"  button  to 
continue  or  the  "Cancel"  button  to  return  to  the  Main-Driver 
menu.  Clicking  the  "OK"  button  causes  the  View-Edit-Selection 
menu  to  appear. 
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Figure  24  Delete-Dialog  Form 


76 


L.  QUERY'SELECTION  FORM 

The  Query-Selection  form  shown  in  Figure  25  allows  a  user 
to  select  one  of  three  predefined  queries  incorporated  into 
the  database.  The  three  queries  available  are:  Networks  by 
Operational  Dates,  Networks  by  Cinc/Components,  and  Networks 
Limited  by  Requirements.  The  user  selects  one  of  these 
queries  and  clicks  the  "Preview"  button  to  invoke  the  selected 
query.  To  cancel  the  Query-Selection  form  at  any  time,  the 
user  selects  the  "Cancel"  button.  Clicking  the  "Cancel" 
button  returns  the  user  to  the  Main-Driver  menu.  The  following 
pages  describe  the  forms  that  will  appear  by  the  query 
selected. 
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Figure  25  Query-Selection  Form 
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1.  M«tworks-by-Op«rational-Dates-Input  Form 

This  form  appears  if  the  Networks  by  Operational  Dates 
juery  is  selected.  The  form  is  shown  in  Figure  26.  On  this 
form  the  user  specifies  the  beginning  and  ending  dates  of  the 
networks  they  want  to  query.  Clicking  the  •'OK”  button  causes 
the  Nets-by-Operational-Dates-Results  form  to  appear  in 
conjunction  with  the  Networks-by-Operational-Dates-Input  form. 
These  forms  are  shown  in  Figure  27.  Clicking  the  "Cancel” 
button  on  this  form  returns  the  user  to  the  Query-Selection 
form. 
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Figure  26  Networks-by-Operational-Dates-Input  Form 


Figure  27  Nets-by-Operational-Dates-Results  Form 
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2.  M«tworks-by-ciNC/Components-lnput  Dialog 

The  Networks-by-CINC/Coinponents-Input  dialog  (shown  in 
Figure  28)  appears  on  the  bottom  of  the  Query-Selection  form 
if  the  Networks  by  CINC/Components  query  is  selected.  The 
user  specifies  the  CINC  and  component  of  the  networks  (s)he 
wants  to  query.  Clicking  the  "Preview"  button  causes  one  of 
three  forms  to  appear  depending  upon  what  information  is 
specified  by  the  user.  If  the  user  specifies  both  a  CINC  and 
a  Component,  then  the  form  Networks-by-CINC-and-Component  will 
appear.  If  the  user  specifies  a  CINC  and  leaves  the  component 
name  blank,  then  the  form  Networks-by-CINC-Al  1-Components  will 
appear.  If  the  user  does  not  specify  either  a  CINC  or  a 
component  (i.e.,  leaves  both  fields  blank),  then  the  form 
Networks-by-All-CiNC/Components  will  appear.  All  three  forms 
look  the  same.  The  difference  between  them  is  that  each  is 
generated  by  a  different  sub-query  depending  upon  the 
information  specified  by  the  user.  An  example  of  one  is 
shown  in  Figure  29.  For  more  information  regarding  these  sub¬ 
queries,  please  refer  to  Chapter  IV,  MRDB  Application  Queries. 
Clicking  the  "Cancel"  button  on  this  form  returns  the  user  to 
the  Main-Driver  menu. 
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Figure  28  Networks-by-CINC/Components-Input  Dialog 


Figure  29  Network-by-CINC-and-Component  Form 
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3.  N«tvorks-Limit«d-by-R«quirements-Input  Form 

This  form  (shown  in  Figure  30)  appears  if  the  Networks 
Limited  by  Requirements  query  is  selected.  On  this  form  the 
user  specifies  the  requirements  of  the  networks  they  want  to 
query.  Clicking  the  "Preview"  button  causes  one  of  two  :orms 
to  appear  depending  upon  what  information  is  specified  by  the 
user.  If  the  user  specifies  a  satisfaction  level,  then  the 
form  Networks-by-Satisf action-Level  will  appear.  If  the  user 
does  not  specify  a  satisfaction  level  (i.e.,  the  user  leaves 
the  field  blank) ,  then  the  form  Networks-by-All-Satisf action- 
Levels  will  appear.  Both  of  these  forms  look  the  same.  The 
difference  between  them  is  that  each  is  generated  by  a 
different  sub-query  depending  upon  the  information  specified 
by  the  user.  An  example  of  one  is  shown  in  Figure  31.  For 
information  regarding  these  sub-queries,  please  refer  to 
Chapter  IV,  MRDB  Application  Queries. 
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Figure  30  Networks-Limited-by-Requirements-Input 
Form 


Figure  31  Networks-by-All-Satisf action-Levels 
Form 
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M.  REPORT-SELECTION  FORM 


The  Report-Selection  form  shown  in  Figure  32  allows  a  user 
to  either  preview  or  print  the  reports  available  in  the 
database.  The  two  available  reports  are  the  Detailed  report 
and  the  Terminal  User  report.  After  selecting  the  desired 
report,  the  user  will  be  prompted  for  a  network  acronym.  The 
user  can  either  enter  a  network  acronym  for  the  network  to  be 
printed,  or  (s)he  can  leave  the  field  blank  to  print  all 
networks.  The  user  then  selects  the  appropriate  button  - 
"Preview",  "Print",  or  "Cancel"  accordingly.  Pressing  the 
"Preview"  button  allows  a  user  to  preview  the  report  before 
printing  it,  pressing  the  "Print"  button  sends  the  report 
directly  to  the  printer,  and  pressing  the  "Cancel"  button 
returns  the  user  to  the  Main-Driver-Menu. 
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Figure  32  Report-Selection  Form 
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VI.  MRDB  APPLICATION  REPORTS 


Reports  are  a  meaningful  way  to  present  data  in  printed 
form  [Ref.  5:p.  396].  Like  a  form,  a  report  can  be  organized 
and  formatted  to  a  user's  specifications  [Ref.  5;p.  396].  A 
report  can  be  previewed  on  a  user's  terminal  screen  or  it  can 
be  directed  to  a  printer  for  hard  copy  printout  [Ref.  4:p. 
140].  In  this  database  application,  two  reports  can  be 
generated,  the  Detailed  report  and  the  Terminal  User  report. 
A  user  can  run  these  reports  for  all  network  requirements  or 
for  a  specific  one.  These  reports  are  discussed  in  the  next 
two  sections. 

A.  DETAILED  REPORT 

The  Detailed  report,  shown  in  Figure  33,  includes  the  data 
fields  that  define  a  network  requirement.  This  report  is 
produced  by  the  Detailed-Main-Report  and  four  subreports  that 
are  linked  to  it.  "A  subreport  is  a  report  that  is  inserted 
into  another  report."  [Ref.  5:p.  464]  A  subreport  contains 
information  related  to  the  main  report  but  due  to  software 
limitations  in  Access,  cannot  be  included  in  the  main  report 
[Ref.  5:p.  472].  For  example,  if  a  table  has  a  one-to-many 
relationship  with  two  or  more  tables  or  queries,  then  a 
subreport  is  required  to  print  all  the  data  in  one  report 


87 


***  Unclassified  ***  :7-Ma\-93 

Unclassified  ~I  NHw«rii  l>Mcnf»(ion Objeclivr  --  - 


88 


~  ^  —  Unclassified 

Figure  33  Detailed  Report  _ ***  Unclassified  **♦  _ _ _ Page  u 


[Ref.  5:p.  472].  These  subreports  are  then  linked  to  the  main 
report  to  produce  the  complete  report  [Ref.  5:pp.  472-473]. 
As  shown  in  Figure  33,  the  Detailed  report  consists  of  five 
sections  -  the  Network  Description  Objective,  the 
Survivability/Technical  Parameters,  the  Originator 
Information,  Reference  information,  and  Connectivity 
information.  These  sections  are  discussed  in  the  following 
paragraphs. 

1.  Network  Description  Objective  Section 

This  section  displays  basic  information  regarding  a 
network  requirement  such  as  the  network  acronym  and  name,  the 
responsible  CINC  and  component,  the  satisfaction  level,  the 
network's  missions  and  other  general  information  regarding  the 
requirement.  This  information  is  obtained  from  the  Network 
table  and  is  produced  by  the  Detailed-Main-Report. 

2.  Survivability/Technical  Parameters  Section 

This  section  describes  the  survivability  and  technical 
parameters  of  a  network  requirement.  It  displays  the  anti¬ 
jamming  and  low  probability  of  intercept  thresholds,  the 
conflict  levels  and  scenarios,  the  bit  error  rate,  the  minimum 
availability,  the  maximum  message  transmit  time,  the  maximum 
allowable  access  time,  and  the  duty  cycle  threshold.  This 
information  is  obtained  from  the  Network  table  and  is  produced 
by  the  Detailed-Main-Report. 
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3.  Originator  Information  Section 

This  section  displays  information  regarding  the  points 
of  contact  for  a  network  requirement.  It  displays  the  names 
of  the  points  of  contact,  their  office  symbols  and  their 
important  telephone  numbers.  This  information  comes  from  the 
POC  table  and  is  produced  by  the  Detailed-POC-Subreport . 

4.  Reference  Information  section 

This  section  displays  the  documents  referenced  by  a 
network  requirement.  It  displays  the  document  title,  author, 
publication  date,  page  numbers,  and  classification  of  these 
documents.  This  information  is  obtained  from  the  Document  and 
Network-Ref -Document  tables  and  is  produced  by  the  Detailed- 
Doc-Subreport  . 

5.  Connectivity  Information  Section 

This  section  displays  the  connectivities  that  make  up 
a  network  requirement.  It  displays  the  connectivity  and  data 
types  of  each  connection,  their  stressed  and  unstressed  data 
rates,  their  operation  mode  and  number  of  circuits,  and 
general  information  regarding  the  terminals  located  at  the 
origin  and  destination  sites  of  these  connections.  This 
information  comes  from  a  composite  of  several  different  tables 
-  the  Connectivity  table,  the  Terminal  table,  the  Terminal- 
Connect  table,  and  the  Terminal  Type  table.  This  section  is 
produced  by  two  subreports  -  the  Detailed-Origin-Subreport  and 
the  Detailed-Destination-Subreport.  The  Detailed-Origin- 


90 


Subreport  prints  out  basic  information  for  each  connectivity 
(such  as  the  connectivity  type,  data  type,  data  rates,  etc.) 
and  information  regarding  the  originating  terminals  of  these 
connections.  The  Detailed-Dest-Subreport  prints  out  the 
information  regarding  the  destination  terminals  of  these 
connections . 

B.  TERMINAL  USER  REPORT 

The  Terminal  User  report,  shown  in  Figure  34,  displays  the 
terminals  and  the  users  who  use  those  terminals  for  all 
connections  of  a  network  requirement.  The  report  is  produced 
by  the  Terminal-User-Main-Report  and  two  subreports  linked  to 
it.  As  shown  in  Figure  34,  the  report  is  broken  up  into  three 
sections  -  the  Network  Description  section,  the  Origin 
User/Terminal  section,  and  the  Destination  User/Terminal 
section.  These  sections  are  discussed  in  the  following 
paragraphs. 

1.  Network  Description  Section 

This  section  displays  basic  information  related  to  a 
network  requirement  such  as  the  network  acronym  and  name,  the 
responsible  CINC  and  component,  the  satisfaction  level,  the 
network's  missions  and  other  general  information  regarding  the 
requirement.  This  information  is  obtained  from  the  Network 
table  and  is  produced  by  the  Terminal-User-Main-Report. 
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Figui  "'  34  Terminal  User  Report 


2.  Origin  User/Terminal  Section 

This  section  displays  the  users  and  the  terminals 
located  at  the  originating  locations  of  each  connectivity  for 
a  network  requirement.  It  displays  the  originating  users  and 
their  locations  as  well  as  the  originating  terminals  and  their 
locations  for  each  connection.  The  information  comes  from  a 
composite  of  three  tables  -  the  Terminal  table,  the  User 
table,  and  Geo-Location  table,  and  is  produced  by  the  Term- 
User-Origin-Subreport  . 

3.  Destination  User/Terminal  Section 

This  section  displays  the  destination  users  and  their 
locations  as  well  as  the  destination  terminals  and  their 
locations  for  each  connection  of  a  network  requirement.  The 
information  comes  from  a  composite  of  three  tables  -  the 
Terminal  table,  the  User  table,  and  Geo-Location  table,  and  is 
produced  by  the  Term-User-Dest-Subreport . 

This  chapter  and  the  two  preceding  ones  described  the  MRDB 
application  of  queries,  forms,  and  reports  in  the  database 
system.  The  next  chapter  describes  how  macros  and  modules  are 
used  to  integrate  these  queries,  forms,  and  reports  into  a 
customized  menu-driven  database  system. 
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VII.  MRDB  APPLICATION  MACROS  AND  MODULES 


This  chapter  describes  the  macros  and  modules  used  by  the 
database  application.  Section  A  defines  each  macro  and 
describes  the  actions  that  result  by  invoking  them.  Section 
B  defines  modules  and  describes  the  "IsLoaded"  function  used 
by  the  database  system. 

A.  MACROS 

Macros  are  used  to  automate  routine  or  repetitive  tasks 
and  integrate  a  set  of  menus,  forms,  queries,  and  reports  into 
a  customized  menu-driven  system.  Macros  consist  of  actions 
that  are  executed  when  a  user  selects  a  particular  option  from 
a  menu  or  a  form.  An  action  could  be  to  open  a  new  form, 
close  a  current  one,  run  a  report,  or  execute  a  query.  This 
database  application  includes  15  macros.  The  following 
sections  briefly  define  the  purpose  of  each  macro  and  describe 
the  actions  performed  by  them. 

1.  Auto-Exec  Macro 

The  purpose  of  the  Auto-Exec  macro  is  to  initiate  the 
MRDB  database.  Executing  this  macro  opens  and  displays  the 
Main-Driver  menu.  From  this  menu,  a  user  can  select  and 
perform  the  functions  available  in  the  menu-driven  system  by 
clicking  the  appropriate  button  on  the  form. 
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Main-Driv«r  Macro 


The  purpose  che  Main-Driver  macro  is  to  open  and 
display  the  forms  ^^-jociated  with  the  Main-Driver  menu.  The 
Main-Driver  menu  allows  a  user  to  select  from  five  functions 
by  point' ng  and  clicking  the  appropriate  button  on  the  menu. 
The  five  choices  and  the  actions  that  result  by  selecting  them 
are  described  below. 

a.  View-Edit  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  View-Edit-Selection  menu. 

b.  Delete  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Delete-Dialog  form. 

c.  Queries  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Query-Selection  form. 

d.  Reports  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Report-Selection  form. 

e.  Exit  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Main-Driver  menu  and  return  to  the  initiating  application. 

3.  View-Edit-Selection  Macro 

The  purpose  of  the  View-Edit-Selection  macro  is  to 
open  and  display  the  forms  associated  with  the  View-Edit- 
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Selection  menu.  A  user  can  select  from  nine  different  buttons 
on  the  View-Edit-Selection  form.  The  nine  buttons  and  the 
actions  that  result  by  selecting  them  are  described  below. 

a.  View  Network  Requirements  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network-Update  form.  When  the  form  is  opened,  the 
macro  displays  the  first  network  reguirement  record  from  the 
Network  table. 

b.  View  CISC  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  CINC-Update  form.  When  the  form  is  opened,  the 
macro  displays  the  first  CINC  record  from  the  CINC  table. 

c.  View  POC  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  POC-Update  form.  When  the  form  is  opened,  the 
macro  displays  the  first  POC  record  from  the  POC  table. 

d-  View  DOC  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Document-Update  form.  When  the  form  is  opened, 
the  macro  displays  the  first  document  record  from  the  Document 
table . 

e.  View  Connectivity  Requirements  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Connectivity-Update  form.  When  the  form  is 
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opened,  the  macro  displays  the  first  connectivity  record  from 
the  Connectivity  table. 

f.  View  Terminal  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Terminal -Update  form.  When  the  form  is  opened, 
the  macro  displays  the  first  terminal  record  from  the  Terminal 
table. 

g.  View  Terminal-Type  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Terminal-Type-Update  form.  When  the  form  is 
opened,  the  macro  displays  the  first  terminal-type  record  from 
the  Terminal-Type  table. 

h.  view  User  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  User-Update  form.  When  the  form  is  opened,  the 
macro  displays  the  first  user  record  from  the  User  table. 

i .  Return  Button 

Clicking  this  button  causes  the  macro  to  close  the 
View-Edit-Selection  form  and  returns  the  user  to  the  Main- 
Driver  menu. 

4 .  Network-Update  Macro 

The  purpose  of  the  Network-Update  macro  is  to  open  and 
display  the  forms  associated  with  the  Network-Update  form. 
The  user  can  select  from  seven  different  buttons  on  the 
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Network-Update  form.  The  seven  buttons  and  the  actions  that 
result  by  selecting  them  are  described  below. 

a.  View  Connectivities  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network -View-Connectivity  form  in  conjunction  with 
the  Network-Update  form. 

b.  Add  Connectivity  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network-Add-Connectivity  form  in  conjunction  with 
the  Network-Update  form.  When  the  form  is  opened,  the  macro 
displays  the  first  connectivity  record  from  the  Connectivity 
table. 

c.  View  POC  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network-View-POC  form  in  conjunction  with  the 
Network-Update  form. 

d.  Add  POC  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network-Add-POC  form  in  conjunction  with  the 
Network-Update  form.  When  the  form  is  opened,  the  macro 
displays  the  first  POC  record  from  the  POC  table. 

e.  View  Document  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network-View-Document  form  in  conjunction  with  the 
Network-Update  form. 
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f.  Add  Document  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network -Add-Document  form  in  conjunction  with  the 
Network-Update  form.  When  the  form  is  opened,  the  macro 
displays  the  first  document  record  from  the  Document  table. 

g.  Return  to  Menu  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Network-Update  form  and  returns  the  user  to  the  View-Edit- 
Selection  menu. 

5.  Network-Add-Connectivlty  Macro 

The  purpose  of  the  Network -Add-Connectivity  macro  is 
to  open  and  display  the  forms  associated  with  the  Network-Add- 
Connectivity  form.  From  the  Network-Add-Connectivity  form  a 
user  can  select  from  three  different  buttons.  These  buttons 
and  the  actions  that  result  by  selecting  them  are  described 
below. 

a.  View  Terminals  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network -Add-Conn-View-Terminals  form  in 
conjunction  with  the  Network-Update  form  and  the  Network -Add- 
Connectivity  form. 

b.  Add  Terminals  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Network-Add-Conn-Add-Terminals  form  in  conjunction 
with  the  Network-Update  form  and  the  Network -Add-Connectivity 
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form.  When  the  form  is  opened,  the  macro  displays  the  first 
terminal  record  from  the  Terminal  table, 
c.  Return  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Network-Add-Connectivity  form  and  returns  the  user  to  the 
Network-Update  form. 

6.  Connectivity-Dpdate  Macro 

The  purpose  of  the  Connectivity-Update  macro  is  to 
open  and  display  the  forms  associated  with  the  Connectivity- 
Update  form.  From  the  Connectivity-Update  form  a  user  can 
select  from  three  different  buttons.  The  three  buttons  and 
the  actions  that  result  by  selecting  them  are  described  below. 

a.  Viei^  Terminals  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Connectivity-View-Terminals  form  in  conjunction 
with  the  Connectivity-Update  form. 

b.  Add  Terminals  Button 

Clicking  this  button  causes  the  macro  to  open  and 
display  the  Connectivity-Add-Terminal  form  in  conjunction  with 
the  Connectivity-Update  form.  When  the  form  is  opened,  the 
macro  displays  the  first  terminal  record  from  the  Terminal 
table. 
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c.  Return  to  Menu  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Connectivity-Update  form  and  returns  the  user  to  the  View- 
Edit-Selection  menu. 

7.  Delete-Dialog  Macro 

The  purpose  of  the  Delete-Dialog  macro  is  to  open  and 
display  the  forms  associated  with  the  Delete-Dialog  form. 
From  the  Delete-Dialog  form  a  user  can  select  from  two 
different  buttons.  The  two  buttons  and  the  actions  that 
result  by  selecting  them  are  described  below. 

a .  OK  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Delete-Dialog  form  and  open  and  display  the  View-Edit- 
Selection  menu. 

b.  Cancel  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Delete-Dialog  form  and  returns  the  user  to  the  Main-Driver 
menu 

8.  Query-Selection  Macro 

The  purpose  of  the  Query-Selection  macro  is  to  open 
and  display  the  forms  associated  with  the  Query-Selection 
form.  From  the  Query-Selection  form  a  user  can  select  from 
three  queries  and  then  select  either  the  "Preview”  button  or 
the  "Cancel"  button.  The  "Preview"  button  causes  the  macro  to 
request  additional  information  for  the  query  whereas  the 
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"Cancel”  button  will  stop  the  query  process  and  return  the 
user  to  the  Main-Driver  menu.  The  four  choices  available  and 
the  actions  that  result  from  them  are  described  below. 

a.  Networks  by  Operational  Dates  and  Preview  Button 
Selected 

Selecting  these  options  causes  the  macro  to  open 
and  display  the  Networks-by-Operational-Dates-Input  form. 

b.  Networks  by  CINC /Components  Selected 
Selecting  this  option  causes  the  macro  to  prompt 

the  user  to  specify  the  CINC  and  component  for  the  query. 
Once  this  information  is  specified,  the  user  can  select  the 
"Preview"  button  to  execute  the  query  or  the  "Cancel"  button 
to  cancel  the  query.  If  the  user  selects  the  "Preview"  button 
then  the  macro  will  execute  and  display  the  results  in  an 
appropriate  form.  (See  Chapter  V,  MRDB  Application  Forms, 
Section  L.2,  for  more  information  on  these  forms).  If  the 
user  selects  the  "Cancel"  button  then  the  macro  will  close  the 
Query-Selection  form  and  return  the  user  to  the  Main-Driver 
menu. 

c.  Networks  Limited  by  Requirements  and  Preview 
Button  Selected 

Selecting  these  options  causes  the  macro  to  open 
and  display  the  Networks-Limited-by-Requirements-Input  form. 
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d.  Cancel  Button  Selected 

Selecting  this  button  causes  the  macro  to  close  the 
Query-Selection  form  and  returns  the  user  to  the  Main-Driver 
menu. 

9.  Networks-by-Operational-Dates-Input  Macro 

The  purpose  of  this  macro  is  to  open  and  display  the 
forms  associated  with  the  Networks-by-Operational-Dates-Input 
form.  From  the  Networks-by-Operational-Dates-Input  form  a 
user  can  specify  the  beginning  and  ending  operational  dates  of 
the  networks  (s)he  wants  to  query.  Once  these  dates  have  been 
entered,  the  user  can  select  the  “OK”  button  to  execute  the 
query  or  the  "Cancel”  button  to  cancel  the  query.  The  two 
buttons  and  the  actions  that  result  by  selecting  them  are 
described  below. 

a.  OK  Button 

Clicking  this  button  causes  the  macro  to  display 
the  results  of  the  query  by  opening  the  Nets-by-Operational- 
Dates-Results  form. 

Jb.  Cancel  Button  Selected 

Clicking  this  button  causes  the  macro  to  close  the 
Networks-by-Operational-Dates-Input  form  and  returns  the  user 
to  the  Query-Selection  form. 

10.  Networks-Limited-by-Requirements  Macro 

The  purpose  of  this  macro  is  to  open  and  display  the 
forms  associated  with  the  Networks-Limited-by-Requirements- 
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Input  form.  From  the  Networks-Limited-by-Requirements-Input 
form  a  user  can  specify  the  criteria  for  the  networks  (s)he 
wants  to  query.  Once  this  information  is  entered,  the  user 
can  select  the  "OK”  button  to  execute  the  query  or  the 
"Cancel"  button  to  cancel  the  query.  The  two  buttons  and  the 
actions  that  result  by  selecting  them  are  described  below. 

a.  OK  Button 

Clicking  this  button  causes  the  macro  to  display 
the  results  of  the  query  by  opening  the  Networks-by-All- 
Satisfaction-Levels  form  or  the  Networks-by-Satisfaction-Level 
form.  The  Networks-by-All-Satisfaction-Levels  form  is  opened 
and  displayed  if  a  user  does  not  restrict  the  query  to  a 
particular  satisfaction  level.  However,  if  a  user  does 
restrict  the  query  to  a  particular  satisfaction  level,  then 
the  macro  will  open  and  display  the  Networks-by-Satisfaction- 
Level  form. 

b.  Cancel  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Networks-Limited-by-Requirements-Input  form  and  returns  the 
user  to  Query-Selection  form. 

11.  Report-Selection  Macro 

The  purpose  of  the  Report-Selection  macro  is  to  open 
and  display  the  reports  associated  with  the  Report-Selection 
form.  From  the  Report-Selection  form  a  user  can  select  to 
preview  or  print  the  Detailed  Report  or  the  Terminal  User 
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Report.  When  a  user  selects  one  of  these  reports,  the  Report- 
Selection  macro  will  prompt  the  user  for  a  network  acronym. 
A  user  can  enter  a  network  acronym  for  the  network  requirement 
(s)he  wants  to  print,  or  (s)he  can  leave  the  field  blank  and 
print  the  report  for  all  network  requirements.  Once  this 
information  is  entered,  a  user  can  then  select  the  "Preview" 
button  to  preview  the  report,  the  "Print"  button  to  print  the 
report,  or  the  "Cancel"  button  to  return  to  the  Main-Driver 
menu.  Each  of  these  buttons  and  the  actions  that  result  by 
selecting  them  are  described  below. 

a .  Preview  Button 

Clicking  this  Litton  causes  the  macro  to  open 
either  the  Detailed-Main-Report  or  the  Terminal-User-Main- 
Report  in  "Print  Preview"  mode. 

b.  Print  Button 

Clicking  this  button  causes  the  macro  to  open 
either  the  Detailed-Main-Report  or  the  Terminal-User-Main- 
Report  in  "Print"  mode. 

c.  Cancel  Button 

Clicking  this  button  causes  the  macro  to  close  the 
Report-Selection  form  and  returns  the  user  to  the  Main-Driver 
menu. 

12 .  Find-Record  Macro 

The  purpose  of  this  macro  is  to  find  a  specific  record 
while  a  user  is  viewing  records  on  a  form.  This  macro  exists 
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for  the  following  tables:  Network,  Connectivity,  CINC,  POC, 
Document,  Terminal,  Terminal-Type,  and  User.  Each  of  these 
tables  has  a  corresponding  form  that  allows  a  user  to  view  and 
edit  these  records.  On  the  bottom  of  each  form  is  a  Find 
dialog  box.  In  the  Find  dialog  box  a  user  can  specify  the 
record  (s)he  wishes  to  locate.  This  information  is  then  used 
by  the  macro  to  find  and  display  the  specified  record  on  the 
form.  [Ref.  5:pp.  546-547] 

13.  Shov-Related-Conn-FOC-Ooc  Macro 

The  purpose  of  this  macro  is  to  keep  the  Network-View- 
Connectivity  form,  or  the  Network-View-POC  form,  or  the 
Network-View-Document  form  (if  one  of  these  forms  is  currently 
opened)  synchronized  with  the  current  network  requirement 
record  as  a  user  moves  from  record  to  record  on  the  Network- 
Update  form.  [Ref.  5:pp.  536-537] 

14.  Show-Related-Terminals  Macro 

The  purpose  of  this  macro  is  to  keep  the  Connectivity- 
View-Terminals  form  (if  opened)  synchronized  with  the  current 
connectivity  requirement  as  a  user  moves  from  record  to  record 
on  the  Connectivity-Update  form.  [Ref.  5:pp.  536-537] 

15.  Return  Macro 

This  is  a  generic  macro  that  can  be  invoked  by  any 
form.  The  purpose  of  this  macro  is  to  close  the  form  that 
invoked  the  macro. 
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B .  MODULES 


Modules  are  procedures  written  in  Access  Basic  for  tasks 
too  complicated  or  complex  for  a  macro  to  handle.  This 
database  includes  one  procedure.  The  procedure  performs  the 
"IsLoaded"  function  to  check  whether  a  form  is  open  or  not. 
This  function  is  invoked  to  keep  two  forms  synchronized.  The 
"IsLoaded"  function  determines  if  the  second  form  is  open 
prior  to  the  database  attempting  to  display  the  forms  in 
synchronized  format.  The  "IsLoaded"  function  was  developed  by 
Microsoft  and  was  imported  into  this  database  from  their 
Northwind  database  application.  A  copy  of  the  code  can  be 
found  in  Appendix  C. 
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VIII.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  underlying  goal  of  this  thesis  was  to  develop  a 
prototype  PC  based  interactive,  graphical  and  user  friendly 
database  system  for  U.S.  Space  Command  that  allows  them  to 
manage  the  MRDB  database  "in-house”.  The  prototype  database 
system  developed  for  this  thesis,  using  Microsoft  Access 
relational  database  system,  is  PC  based,  is  interactive,  is 
graphical,  is  user  friendly  and  will  allow  U.S.  Space  Command 
to  manage  their  database  "in-house",  therefore  achieving  its 
stated  purpose.  Traditional  database  design  methodologies 
were  used  to  develop  the  prototype.  Microsoft  Access  allowed 
the  prototype  database  system  to  be  developed  quickly,  taking 
full  advantage  of  the  graphical  capabilities  available  in 
Windows.  These  capabilities  provided  the  visual  and  graphical 
features  desired  by  U.S.  Space  Command.  The  six  phase 
database  design  process  ensured  that  a  functional  database 
system  would  be  developed.  Even  though  this  prototype 
database  system  achieved  its  desired  goals,  improvements  can 
be  made  as  discussed  in  Section  B. 

It  should  be  noted  that  the  database  system  developed  for 
this  thesis  is  a  prototype  and  as  such  should  not  be 
considered  a  final  product  for  U.S.  Space  Command.  While  the 
prototype  is  a  solid,  workable  database  system,  there  are 
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three  actions  that  should  be  accomplished  before  its  final 
implementation : 

1 .  Convert  the  current  MRDB  database  into  the  new  MRDB 
structure  defined  in  this  thesis. 

2.  Test  and  fully  evaluate  the  prototype  database  system 
with  the  new  MRDB  structure. 

3.  Obtain  feedback  from  users  on  their  functional 
requirements  (i.e.,  queries  and  reports). 

Once  these  actions  have  been  accomplished,  U.S.  Space 
Command  will  then  be  able  to  use  the  application  as  a 
production  system.  It  should  be  noted,  however,  that  in  order 
for  U.S.  Space  Command  to  successfully  manage  the  database 
"in-house",  attention  must  be  given  to  database  administration 
functions  -  such  as  data  integrity,  database  security,  backup, 
and  recovery.  Microsoft  Access  provides  some  of  these 
administration  functions. 

Access  can  enforce  referential  integrity  rules  if  the 
"Enforce  Referential  Integrity"  option  is  selected  by  the 
designer  of  the  database.  Referential  integrity  rules  prevent 
a  user  from  accidentally  deleting  related  data  from  the 
database  and  helps  ensure  that  data  in  the  database  is  related 
in  a  valid  way.  [Ref.  5:p.  54] 

Access  also  provides  security  by  assigning  each  authorized 
person  a  unique  user  name  and  a  four-digit  personal  ID  number. 
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A  logon  dialog  will  then  be  used  to  prevent  unauthorized  users 
from  accessing  the  database  system.  [Ref.  5;p.  612] 

Backing  up  a  database  is  one  of  the  most  important 
administrative  functions  that  needs  to  be  performed  on  a 
regular  basis.  Backing  up  the  database  protects  the  user  from 
any  major  loss  or  damage  to  the  database.  Procedures  on  how 
often  a  database  should  be  backed  up  depend  upon  the 
importance  of  the  data  and  how  often  it  is  updated.  Backing 
up  a  database  in  Microsoft  Access  is  easy  because  the  entire 
database  is  stored  in  one  file.  [Ref.  5:p.  611] 

Access  also  provides  some  rudimentary  recovery 
capabilities.  If  an  Access  application  terminates  before  a 
user  has  a  chance  to  close  it,  then  the  database  can  be  left 
in  an  inconsistent  state  and  may  need  to  be  recovered.  When 
a  user  tries  to  open  the  database,  Access  will  automatically 
check  for  any  errors  and  display  a  message  indicating  whether 
the  database  is  in  need  of  repair.  If  so,  a  user  can  select 
the  OK  button  and  Access  will  repair  the  database.  [Ref.  5:p. 
628] 

We  recommend  that  a  database  administrator  be  assigned  to 
maintain  the  MRDB  database  to  ensure  that  the  above  functions 
are  performed. 

A.  ADVANTAGES  AND  BENEFITS  OF  THE  PROTOTYPE  DATABASE  SYSTEM 

The  current  operating  environment  requires  U.S.  Space 
Command  to  task  its  subcontractor  to  run  queries  and  reports. 
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The  major  advantages  and  benefits  of  the  prototype  database 
system  over  this  method  of  operation  are  discussed  below. 

1.  The  database  system  uses  a  graphical  user  interface 

The  prototype  database  system  uses  extensive  visual 

features  to  make  the  database  system  more  user  friendly. 
Standard  graphical  user  interface  elements  such  as  pull-down 
menus,  forms,  buttons,  scroll  bars,  etc.  enhance  the 
readability  and  usability  of  the  database  system.  Macros  link 
the  various  forms,  menus,  queries  and  reports  used  by  the 
database  system  into  a  customized  menu-driven  system.  This 
menu-driven  capability  combined  with  the  graphical  features 
available  in  Access  provides  a  user  friendly  environment. 

2.  The  database  system  is  interactive 

The  prototype  database  system  allows  a  user  to  access 
and  manipulate  the  data  in  the  database  interactively.  This 
allows  a  user  to  view  records  or  execute  a  query  or  a  report 
immediately  from  a  personal  computer  without  having  to  wait 
for  the  services  of  a  contractor.  This  greatly  decreases  the 
turn  around  time  to  obtain  information. 

3.  The  database  system  can  be  managed  "in-house" 

With  a  PC  based  system,  U.S.  Space  Command  will  be 
able  to  manage  the  MRDB  database  "in-house",  i.e.,  it  will  no 
longer  need  the  services  of  a  contractor  to  update  or  query 
the  database.  U.S.  Space  Command  will  now  have  the  capability 
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to  update  the  database  themselves  and  execute  and  run  common 
queries  and  reports  easily. 

4.  The  database  system  will  save  U.8.  Space  Command  time 

and  money 

If  U.S.  Space  Command  uses  this  database  system  to 
manage  the  MRDB  "in-house”,  then  a  contractor  is  no  longer 
needed  to  maintain  the  MRDB  database.  This  saves  money.  In 
addition  there  will  no  longer  be  the  time  delays  that  occur 
when  using  a  contractor.  For  example,  instead  of  U.S.  Space 
Command  requesting  a  query  or  a  report  and  waiting  for  the 
contractor  to  provide  it,  U.S.  Space  Command  will  now  be  able 
to  do  these  tasks  themselves  immediately. 

B .  RECOMMENDATIONS 

Even  though  the  prototype  database  system  achieved  its 
desired  goals,  improvements  can  still  be  made. 

1.  Add  more  reports  to  the  database  system 

The  prototype  database  system  produces  the  two  most 
critical  reports  -  the  Detailed  report  and  the  Terminal  User 
report.  U.S.  Space  Command  uses  other  reports  periodically 
that  need  to  be  included  in  the  system.  They  are  the  Form  772 
report,  the  Terminal  Summary  Report,  the  Summary  report,  and 
the  Requirement  Summary  reports. 

2.  Add  a  Print  Option  to  the  Query  Application 

When  a  user  queries  the  database  for  network 
requirements,  a  listing  of  the  networks  that  match  the  search 
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criteria  is  printed  on  the  screen.  A  user  cannot  produce 
these  results  by  invoking  a  predefined  report.  A  "print" 
option  would  be  a  nice  feature  to  include  in  the  Query 
application.  The  "print"  option  could  be  used  to  print  the 
results  of  the  query  or  to  generate  a  report  using  the  results 
of  the  query  as  the  input. 

3.  More  queries  could  be  added  to  the  database  system 

Included  into  the  design  of  the  database  system  are 
three  of  the  more  common  queries  used  by  U.S.  Space  Command. 
However  several  other  predefined  queries  could  also  be 
incorporated  into  the  database  system.  In  addition,  the  Query 
by  Example  feature  available  in  Access  could  be  included  as  a 
option  in  the  database  system  for  ad  hoc  queries  requested  by 
knowledgeable  users. 

4.  A  summary  log  of  a  user's  session  should  be  added 

A  summary  log  of  a  user's  session  could  be  included  in 
the  database  system.  This  log  should  show  the  actions  that 
occurred  during  a  terminal  session  and  the  results  of  those 
actions . 

5.  A  extensive  HELP  facility  should  be  included  in  the 

database  system 

Even  though  a  rudimentary  HELP  system  is  included  in 
the  prototype  database  system,  it  would  be  extremely  useful  to 
have  a  context-sensitive  comprehensive  HELP  system  similar  to 
those  found  in  other  software  applications. 


C.  CLOSING  REMARKS 

The  prototype  database  system  developed  for  this  thesis 
shows  how  U.S.  Space  Command  can  benefit  by  its 
implementation.  The  prototype  database  system  has  several 
advantages  over  the  existing  one  -  it  is  graphical, 
interactive,  user  friendly,  and  will  allow  U.S.  Space  Command 
to  manage  the  MRDB  database  "in-house".  By  implementing  this 
database  system,  U.S.  Space  Command  will  be  able  to  save  both 
time  and  money  by  not  having  to  rely  on  a  contractor  to  query 
and  maintain  the  database.  The  intent  of  this  thesis  was  to 
develop  an  alternative  database  system  for  U.S.  Space  Command 
that  would  be  more  efficient  and  more  cost  effective  than  the 
current  one.  The  Access  version  of  the  MRDB  achieves  this 
objective. 
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APPENDIX  A  -  MRDB  TABLES 


Field 

Data  Type 

Notes 

Table:  CINC  I 

CINC  name 

te*t<11) 

name  of  CINC,  agency  or  primary  service 

Table:  aMPONEMT  | 

CINC  name 

text(ll) 

rtame  of  CINC,  agency  or  primary  service 

co«Donent 

text(8) 

a  component  or  service  of  a  CINC 

1  Table:  CONNECTIVITY 

connectivitv  ID 

counter 

uniquely  identifies  a  connectivity;  indexed 

network  id 

long 

integer 

foreign  key 

connectivity  type 

text  (5) 

conf ig:“pt-pt,  pt-mp,  rptbk,  hbspk,  bdcst,  or  conf“ 

data  type 

text  (5) 

"data,  voice,  image,  video,  or  fax" 

secure  data  transmission  rate 

text  (1) 

indicates  if  the  data  transmitted  must  be  secured  or  encrypted 

ccsd  nuitjer 

text  (8) 

Command  Comnuni cat  ions  Service  Designator  number;  unique  id  for 
circuits,  package  circuit,  truck  circuits;  major  control  element 
in  DISA  database; 

ccsd  restore  priority 

text(2) 

relative  importance  of  circuit  for  restoration 

isdb  number 

text  (13) 

control  nuifcer  which  uniquely  identifies  a  requirement  in  the  ISDB 

system  name 

text  (10) 

name  of  the  satellite  system  carrying  the  circuit 

mode  of  operation 

text  (A) 

"fdux,  hdux,  splx" 

nuriier  of  circuits 

integer 

nimiber  of  circuits  involved  in  the  connectivity;  nurber  between  0 
and  99 

connectivity  critical 

text  (1) 

identifies  if  connectivity  critical  to  network 

stressed  data  rate  obj 

MMH| 

objective  kbps  supported  in  presence  of  jamming  or  scinti 1 lation 

stressed  data  rate  thrsh 

double 

threshold  kbps  supported  in  presence  of  janriing  or  scintillation 

double 

total  stressed  throughput  objective  of  a  connectivity 

stressed  thru-put  rate  thrsh 

double 

total  stressed  throughput  threshold  of  a  connectivity 

instressed  data  rate  obj 

double 

objective  kbps  w/o  janming  or  scintillation;  if  no  aj,  leave  blank 

unstressed  data  rate  thrsh 

double 

threshold  kbps  w/o  janming  or  scintillation;  if  no  aj,  leave  blank 

unstressed  thru-put  rate  obj 

double 

total  unstressed  throughput  objective  of  a  connectivity 

unstrssed  thru-put  rate  thrsh 

double 

total  unstressed  throughput  threshold  of  a  connectivity 
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document  10 

counter 

document  title 

text (70) 

author 

textdS) 

publ i cat  1  on  date 

ttm/dd/yyyy 

classi f icat ion 

textlS) 

Tatbe:  GEO-Location 


state-country  code 


area  code 


country  abbreviation 


full  location  name 


latitude  degrees 


latitude  mi nutes 


latitude  seconds 


latitude  hemisphere 


longitude  degrees 


longitude  minutes 


longitude  seconds 


longitude  hemisphere 


Table:  NETWORK 


net- ID 


network  name 


mission  definition 


cine 


cine  component  name 


network  acronym 


security  classification 


cine  priority 


global  priority 


rqpit  type  obj 


rqmt  type  thrsh 


rqmt  type  critical 


rqmt  duration 


inique  identifier  for  a  dociment 


requirement 


textdS)  organization  or  person  who  created  the  referenced  doctitient 


tnn/dd/ywv  publication  date  of  the  reference  dociment 


overall  classification  of  the  reference  docianent 


eoqraohic  reference  code 

text(A) 

uni 

que 

textlS) 


text(2) 


textd) 


text(2S) 


integer 


textd) 


integer 


integer 


integer 


textd) 


counter 


text(35) 


textdOO) 


textdO) 


textlS) 


textdO) 


textd2) 


text(3) 


text(2) 


textdl) 


textdl) 


textd) 


integer 


unique  identifier  for  each  geographic  location 


location  of  a  comnunication  terminal  or  facility  as  listed  in  USDS 
publication 


state  or  country  of  a  user's  location  according  to  federal 
standard 


identifies  the  DCA  area;  between  1  and  9 


five  character  abbreviation  of  a  foreign  country  or  domestic  state 


full  spelling  of  the  coded  8  character  DISA  user  location 


degrees  away  from  the  equator  of  the  user's  location;  between  0 
and  90 


minutes  away  from  the  equator  of  the  user's  location;  between  0 
and  60 


seconds  away  from  the  equator  of  the  user's  location;  between  0 
and  60 


latitudinal  hemisphere  in  which  the  user's  is  located  “N"  or  “S" 


degrees  away  from  the  zero  meridian  of  the  user's  location; 
between  0  and  180 


minutes  away  from  the  equator  of  a  user's  location;  between  0  and 
60 


seconds  away  from  the  zero  meridian  of  a  user's  location;  between 
0  and  60 


longitudinal  hemisphere  of  the  user's  location;  "E"  or  "W" 


network  identification  nuiber  that  uniquely  identifies  a  network 


description  of  network 


end  mission  of  network  requirement 


responsible  cinc/agency  for  network  requirement;  indexed 


specific  component  or  service  of  network  req;  indexed  _ 


network  acronym  that  uniquely  identifies  a  network  _ 


overall  security  classification  of  network;  "unclassi f ied"  or 
"secret";  not  above  secret 


priority  of  requirement;  assigned  by  cinc/agency 


assigned  by  ISDB 


requirement  type  objective;  type  of  support;  "full  period  or  on 
call" 


requirement  type  threshold;  type  of  support;  full  period  = 
dedicated;  on-call  *  contingency  _ 


if  critical  for  completion  of  unit's  mission;  "y  or  n" 


duration  of  re^t;  usually  use  for  short  term  requirements;  in 
days 
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rqpt  begin  date 

mn/dd/yyw 

first  date  of  validity;  nm/dd/yy 

rqmt  end  date 

mm/dd/yyyy 

date  no  longer  valid;  nm/dd/yy 

isdb  status 

textCIS) 

status  of  req.  thru  the  validation  process 

satisfaction 

textd) 

present  level  of  satisfaction  for  req;  “U-unsat,  P-partial,  F- 
future,  S-satisfied" 

primary  system 

text(12) 

primary  system  that  satisfies  the  retjnt;  satellite  system  or  freq 
band 

secondary  system 

text(12) 

backup  system  which  satisfies  the  reqmt 

netuoric  excluded 

textd) 

flag  a  network  as  being  deleted  from  the  MRDB 

network  critical 

textCD 

flag  a  network  if  critical  for  completion  of  a  unit's  mission 

aj  required 

aj  critical 

textd) 

anti-jam  requirement  critical  to  the  network?;  "y,n" 

aj  level  obj 

integer 

expected  power  lovel  of  janmer;  0  -  4 

aj  level  thrsh 

integer 

threshold  power  level  of  janmer;  0  -  4 

aj  dist  obj 

integer 

anti-jam  distance  objective;  distance  between  user  location  and 
janmer  location;  0-3 

aj  dist  thrsh 

integer 

anti-jam  distance  threshold;  threshold  distance  between  user 
location  and  janmer  location 

Ipi  required 

low  probability  of  intercept  required  for  the  network?;  "y,n“ 

Ipi  critical 

text(1) 

low  probability  of  intercept  critical  to  the  network?;  '*y,n' 

Ipi  dist  obj 

integer 

Ipi  distance  objective;  distance  from  user  that  there  is  a  low 
probability  of  signal  intercept;  1  -  3 

Ipi  dist  thrsh 

integer 

Ipi  distance  threshold;  threshold  distance  from  the  user  that 
there  is  a  Ipi;  1  -  3 

emp  critical 

textd) 

electromagnetic  pulse  protection  critical;  is  harqening  EMP 
protection  critical  to  the  operation  of  the  network  requirement; 
"y,n" 

erap  obj 

textd) 

emp  objective 

emp  thrsh 

textd) 

emp  threshold 

nsp  required 

textd) 

nuclear  scintillated  protection  required?;  "y,n";  does  network 
need  to  transmit  through  a  nuclear  scintillated  environment 

maxout  obj 

integer 

in  seconds,  the  maxinxjn  time  a  network  transmission  may  be 
interrupted  due  to  weather;  between  0  and  99999  secs 

maxout  thrsh 

integer 

in  seconds,  the  threshold  max  time  a  network  transmission  may  be 
interrupted  due  to  weather;  between  0  and  99999  secs 

min  avai 1  obj 

double 

objective  minimun  percent  of  time  a  network  needs  to  be  available 
to  the  user;  percent  0-100 

min  avai  1  thrsh 

double 

threshold  min  percent  of  time  a  network  needs  to  be  available  to  a 
user;  percent  0-100 

avg-cal Is-per-hour 

integer 

frequency  of  calls  per  hour  made  by  the  user 

avg- length-of -cal  1 

double 

in  minutes  (ex  11.5),  the  avg  length  of  each  call  or  transmission 

duty  cycle  critical 

textd) 

is  duty  cycle  requested  critical  to  the  operation  of  the  network?; 
"y,n'' 

dutv  cycle  obj 

double 

objective  percent  a  network  is  required  to  support  a  transmission 

duty  cycle  thrsh 

double 

ber  critical 

textd) 

is  bit  error  rate  (BER)  critical  to  the  operation  of  the  network 

ber  mantissa 

double 

mantissa  of  BER 

ber  exponent  obj 

integer 

identifies  the  objective  exponent  of  the  max  BER  (service  quality) 
required  by  the  network;  0  -  99 
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ber  exponent  thrsh 

integer 

conf 1 tct_1 

textd) 

conflict  2 

text(l) 

conf 1 ict  3 

text(l) 

conflict  4 

text(l) 

conflict  5 

textd) 

conflict  6 

text(1) 

conf 1 i ct_7 

textd) 

conf 1 i ct  8 

textd) 

scenario  1 

textd) 

scenario  2 

textd) 

scenario  3 

textd ) 

scenario  4 

textd) 

scenario  5 

textd) 

scenario  6 

text( 1 ) 

scenario  7 

textd ) 

scenario  8 

textd) 

■ax - mean- xmi t - 1 i me- ob j 

integer 

max -mean-xmi t • t ime- thrsh 

integer 

max-mean-xmi t • t ime-cri t 

textd) 

max- al low-access- time-obj 

integer 

max-al low-access-time- thrsh 

integer 

max-al low-access- time-critical 

textd) 

anti-spoof  critical 

textd) 

global-reach/global-power  mission 

integer 

net  mission  essential 

integer 

net  US  control 

textd ) 

net  access  critical 

textd) 

command  abbr 

text(2) 

mi  Istar- loaded 

textd) 

primary  mission 

integer 

secondary  mission-1 

integer 

secondary  miss  ion- 2 

integer 

last  update 

date 

identifies  the  threshold  exponent  of  the  max  BER  (service  quality) 
required  by  the  network;  0  -  99 


does  network  need  to  be  operational  during  conflict  level  1 
(peace) 


level  2  (low  intensity  conflict) 


level  3  (crisis) 


level  4  (theater  conventional  war) 


level  S  (global  conventional  war) 


level  6  (theater  nuclear  war) 


level  7  (strategic  nuclear  war) 


level  S  (post-attack/reconstruction) 


n/w  is  to  be  operational  in  peace  scenario 


operational  in  tow  intensity  conflict  scenario 


operational  in  conventional  conflict-east  scenarios 


operational  in  conventional  conflict-west  scenarios 


operational  in  conventional  conf lict-europe  scenarios 


operational  in  theater  nuclear  scenarios 


operational  in  global  nuclear  scenarios 


operational  during  reconstruction  scenarios 


objective  max  time  allowable  for  a  call  to  be  received  after 
transmission;  99999 


threshold  max  time  allowable  for  a  call  to  be  received  after 
transmission;  this  field  is  most  critical  in  ITU&A  networks 


maximun  mean  transmit  time  critical?;  ” 


objective  max  allowable  access  time  to  receive  system  access  after 
a  requirement;  between  0  and  99999 


threshold  max  allowable  access  time  to  receive  system  access  after 
a  requirement;  between  0  and  99999 


indicates  if  the  anti-spoof  capability  of  the  network  is 
critical?;  "y,n" 


AF  global  reach/global  power  functional  mission  areas;  1  - 


is  network  essential  to  the  mission?;  1  -  3 


is  entire  satellite  control  sytem  under  u.S.  control?;  "y,n" 


is  the  availability  of  the  network  critical?;  "y.n" 


abbreviation  of  the  command  name 


is  requirement  included  in  MILSTAR  loading  analysis?;  "y.n" 


three  digit  nertjer  describing  the  primary  mission  of  the  network _ 


three  digit  nimber  describing  the  secondary  mission  of  the  network 


three  digit  nutter  describing  the  tertiary  mission  of  the  network 


data  of  the  last  update  of  the  network  table 
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Table:  HetMork-POC 


network  ID 


Table:  Hetuork-Ref-OocUKnt 


doccnent  ID 


page  nurber 


Table:  POC 


oc  id 


poc  full  name 


office  symbol 


address 


city 


state 


zip  code 


commercial  phone 


dsn  phone 


stu  telephone  number 


secure  fa*  ncmber 


unsecure  fax 


Table:  Terainal 


terminal  ID 


terminal  nomenclature 


user- ID 


geo-ref-code 


serial  number 


region 


reporting  designator 


activation  date 


deactivation  date 


remarks 


Table:  Terainal -Connect 


connectivity  ID 


long 

integer 

unique  identifier  of  a  network  requirement 

long 

integer 

unique  identifier  of  a  point  of  contact 

1 

Long 

integer 

unique  identifier  of  a  docunent 

long 

integer 

unique  identifier  of  a  network  requirement 

textdS) 

specific  page  nuiber(s)  in  the  docunent  where  the  network 
information  is  located 

counter  unique  ntirber  assigned  to  a  point  of  contact  (POCO 


text(30)  name  of  the  point  of  contact  (POC)  for  the  network  re<|tit. 


text(12)  office  code  in  mailing  address  of  the  poc 


text(30)  first  line  of  poc  address 


text(20)  city  mailing  address  of  poc 


text (2)  two  character  state  code  for  poc  address 


text(IO)  mailing  address  ZIP  code  for  poc 


text(16)  coninercial  telephone  nuiber  for  the  POC 


text(IO)  poc's  phone  nurber  in  the  defense  switch  network 


text(16)  telephone  nunber  for  the  POC's  stu  phone 


text(16)  telephone  nuiber  fpr  the  POC’s  secure  fax 


te*t(16)  telephone  nuiber  for  the  POC's  unclassified  fax 


counter  terminal  identification  nuiber 


text(50>  unique  name  or  designator  given  to  a  terminal;  indexed 


integer  nuiber  uniquely  identifing  a  user;  indexed 


text(4)  unique  identifier  for  each  geographic  location;  indexed 


text(IO)  serial  nuiber  of  the  terminal 


text(2)  region  code  for  this  terminal  location 


text(50)  DISA  assigned  unique  designator  for  DSCS  terminals 


mm/dd/yyyv  actual  or  projected  actiyation  date  of  the  terminal 


mm/dd/yyyy  actual  or  projected  deactivation  date  of  the  terminal 


text(SO)  remarks  regarding  the  characteristics  or  configuration  of  a 
terminal 


long  unique  identifier  for  a  connectivity 

integer 


long  unique  identifier  for  a  terminal 

integer 
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or i gin-destination- field 

text(6) 

identifies  the  terminal  as  cither  being  a  origin  or  destination  1 

terminal;  "origin"  or  “dest"  | 

1  Table:  Terminal -Type  I 

1 - 

nomenclature 

textdS) 

unique  name  of  terminal 

f  req 

text(3) 

indicates  the  frequency  band  in  which  the  terminal  is  designed  to 
operate;  “UHF,  SHF,  EHF,  or  URK" 

mobi 1 i ty 

text(6) 

indicates  the  mobility  employed  by  the  terminal;  "Fixed,  Mobile, 
or  Trans" 

platform 

text(5) 

indicates  the  specific  type  of  platform  employed  by  the  terminal; 
“Ship,  Sub,  Air,  Man,  Truck,  or  Fixed" 

antenna  size 

integer 

indicates  the  diameter  in  feet  of  the  antenna  matched  to  the 
terminal 

LOW  eirp 

double 

low  end  of  range  of  radiated  power  available  from  a 
terminal/antenna  configuration;  0  -  999 

high  eirp 

double 

high  end  of  range  of  radiated  power  dvailable  from  a 
terminal /antenna  configuration;  0  J99 

low  gt 

integer 

low  end  of  range  of  receive  sensitivity  available  with  a 
terminal/antenna  configuration;  0-99 

high  gt 

integer 

hign  end  of  range  of  receive  sensitivity  available  with  a 
terminal/antenna  configuration;  0  -  99 

min  data  rate 

double 

indicates  the  miniimin  data  rate  (kbps)  that  the  terminal  is 
designed  to  allow;  0  -  9999.99 

max  data  rate 

double 

indicates  the  maxinun  data  rate  (kbps)  that  the  terminal  is 
designed  to  allow;  0  -  9999.99 

Table:  User  || 

user  i  d 

integer 

unique  identifier  of  a  user 

user -name 

textdS) 

user  (node)  identifier  of  a  connectivity 

geo-ref-code 

text(4) 

unique  geographic  reference  code  of  user;  indexed 

user* region 

integer 

geographic  region  where  the  user  is  located.  Values  1-31. 

(Source  for  many  of  these  data  elements:  ARINC  Research  Corporation,  Software  User's  Manual  for  the  HILSATCOM  Planning 
Support  System.  Version  5.2,  June  1992) 


APPENDIX  B  -  MRDB  QUERIES 

This  appendix  provides  a  complete  listing  of  all  the  queries 
used  by  this  database.  They  are  as  follows: 

CINCs-in-Alpha-Order 

Comp-in-Alpha-Order 

Comp-in-Alpha-Order-for-Network-Update-Form 

Conn-and-Net-ID 

Database  Diagram 

Detailed-Dest-Subrep-Query 

Detailed-Doc-Subrep-Query 

Detailed-Network-Rep-Query 

Detailed-Orig-Subrep-Query 

Detai led-POC-Subrep-Query 

Doc-Tit le-and-ID 

Geo-Loc-Codes 

Net-Acronym-ID 

Nets-by-Operational-Dates-Results 
Networks-All-Satisf action-Levels 
Networks-by-Al 1 -CINC/ Components 
Networks-by-CINC-All-Components 
Networks-by-CINC-and-Component 
Networks-by-Satisfaction-Level 
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POC-Name-ID-List 

Term-Nomenclature-and-ID 

Term-Type~Term-Subform 

Term-User-Dest-Subrep-Query 

Term-User-Origin-Subrep-Query 

Term-User-Query 

Term-User-Subrep-Query 

Terminal-Connectivity-Query 

Terminal-Location-Info 

Terminal-Type-Sorted 

Terminal-User-Rep-Query 

User-Location-Info 

User-names-and-IDs 

User-Term-Subform-Query 

View-Conn 

View-Doc 

View-POC 

View-Terminals 
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APPENDIX  C  -  ISLOADED  FUNCTION 


Programming  code  for  the  IsLoaded  function.  Code  is  written 
in  Microsoft  Access  Basic. 

Function  IsLoaded  (MyFormName) 

'  Accepts:  a  form  name 

’  Purpose:  determines  if  a  form  is  loaded; 

'  Returns:  True  if  specified  form  is  loaded; 

False  if  the  specified  form  is  not  loaded. 

Dim  i 

IsLoaded  =  False 
For  i  =  0  To  Forms. Count 
I f  Forms ( i ) . FormName 
IsLoaded  =  True 
Exit  Function 
End  If 
Next 

End  Function 

(Source:  Microsoft  Corporation,  Microsoft  Access  Northwind 
Database  Example,  1992) 


-  1 

=  MyFormName  Then 

'  Quit  function  once  form  has 
'  been  found. 
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